I have a custom board that uses the LM3S9B90 part. Everything is working exept for one issue that I am struggling with.
On my first prototype board, fresh off the line, I could use my Windows Test App to download my application into Flash via the Ethernet port. Life was good.
I made a few design changes and received my first production board. My first attempt to download my code into Flash failed with a "BOOTP timeout error". After some investigation I found that if I simply held the RST pin low, then started the download, then released the RST pin, it would work. I then fired up WireShark, and found that when I applied power to the prototype board, after about .3 seconds I would see BOOTP traffic. Repeating this for the production board yielded no traffic until I toggled the RST line.
I then considered that it might be related to the BOOTCFG register. I have not knowingly done anything to this register, and the default IO pin, which I believe to be Port H pin 7, is used the same on both boards.
I also looked at the RST pin at power up and it looks the same for both boards.
The only obvious difference between the two boards is the date code on the part. The prototype board is LM3S9B90IQC80C5SD $A-1BP176H. For the production board it is LM3S9B90IQC80C5SD $A-21P119H.
Also, I have multiple copies of each version of the board, and they all behave the same. And I use the LMFlash program to unlock the part to go back to the "factory fresh" state.
I am looking for any suggestions that anyone may have.
Thanks,
Jeff
Jeff,
That certainly is some interesting behavior. Can you use LMFlash to download your code via Ethernet to the production boards? Do the timeouts continue after you unlock the part with LMFlash?
John,
I get the same results with LMFlash as I do with my Test App.
Once the part is programmed, I can update it all day long with no problems. The issue only happens when the part is blank.
Can you get into the part and see where the code is stuck and what is in the 120 bytes after the stack pointer?
I would do this if I knew how. If the part is blank, what code I am looking for - the ROM code? Can I use the debugger to examine the state of the ROM code execution?
A few hints would be greatly appreciated.
If you have a debugger that can attach to a running part without resetting it, you can examine the state of the part while it is running in the ROM bootloader. I've briefly used IAR for this (looking at a running part but not during the bootloader). Another member of the Stellaris team uses OpenOCD and GDB.
1) All I have is the debug card that comes with the Eval Kit and CCS5 - will that work?
2) How do we determine if the part is even running?
3) Was my assumption about the default port and pin for the BOOTCFG correct?
1. Yes, I got a similar setup to work. Go into the CCS debug configuration for a project. In the "Target" tab only these three checkboxes should be checked: "Halt the target before any debugger access","Connect to the target on debugger startup", and "When assembly stepping".
Then begin debugging. In the debug pane, right click "Stellaris In-Circuit Debug Interface" and select "Disconnect Target". Then use LMFLASH to erase the flash on the part and then power cycle your board. Now right click "Stellaris In-Circuit Debug Interface" and select "Connect Target". You should be able to look at memory and the registers.
To verify that a reset is not occurring, repeat the connect, power cycle, and disconnect process several times. The program counter should come up with different values since you are connecting the debugger at different points of the ROM bootloader's execution.
2. If the debugger can be run with the part, that means the part is running. If not, the part is either not running or something is wrong with the debug path.
3. Your assumption is correct. The datasheet reports 0xFFFFFFFE as the default BOOTCFG value, which corresponds to PH7 in the PORT and PIN fields of the register.
Thanks so much for your help with this. Using your suggestions, I found that things were getting hung up waiting for the SSIO Status Register to indicate that the reciever was empty. One of the changes I made to the production board was to connect the SSIO lines to a serial PROM that is used for FPGA configuration. If I hold the FPGA in reset (so it is not accessing the PROM) then everything works!
Thanks again,