In SX Microcontrollers, SX/B Compiler and SX-Key Tool, Peter Van der Zee wrote:

Hi Dan;

Well, how do you like this one for coincidences...... Yesterday I posted that I never had a problem programming or debugging SX48s at 3 volts. Today the story has changed, and while I can program them fine, I had some strange results in debugging as well as running programs. But not consistently.

So I was able to track my problem down....  a very subtle situation, and Dan your problem may be the same although it had nothing to do with 3 volts or 5 volts. And I think this issue holds for SX48/52 only, I do not believe the SX28 family suffers the same way from these symptoms.

A couple of interactive things are afoot here. So it turns out that the current documentation, Rev 1.5 datasheet of the SX48BD has (at least) one error in it. It states (page 41) what the register states are after various reset scenarios, and in particular we are interested in the FSR register (the only one I have messed with), and it is incorrect ..... my findings are that with EXTERNAL reset, that is grounding the MCLR pin, the FSR always returns to 00 and not to 8X as stated. The implication being that RAM bank0 is selected (not visible in the IDE), and writing to memory locations in this bank can be problematic as they are not conveniently accessible. So while you think your progam is doing the right thing, it's messing with a piece of invisible memory.

Now the second part. Note that on that descriptive page 41, at the bottom Note 3 indicates uncertain and inconsistent behaviour by the debugger as to the state it is leaving some registers in. I believe that it should be expanded to cover the FSR as well, and perhaps other registers I have not delved yet into, or other reset sources. Please note that pressing the RESET button on the IDE's debugger control panel yields very different results from a physical 'hard reset' on the chip's MCLR pin.

So what all this means -at least in my case- is that uncertain starting conditions of the FSR can cause initial programming statements (typically configuration stuff) to end up in an unexpected area of memory, and the debugger is the instrument that leaves it in that inconsistent and unknown state.

So my solution now is to have the very first instuction after the reset jump from $FFF be a bank$10 statement to initialize the FSR properly. And why I had not knowingly run accross this situation before, is that I almost always start my programs with a standard template, and that happens to have the requisite bank instruction early enough to point at the desired memory and yield proper results.

Experiment with this and try it Dan, it might be the answer for you.

Cheers,

Peter (pjv)

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=245014#m245293

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2008 (http://www.dotNetBB.com)