This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi forum,
I had a bit puzzle today when I used SDFlash boot from serial A option. The sdflash process passed, the message said erase, program, verify success and after I reset the chip i had a blinking LED that indicating at least that part runs ok.
Then I checked my communication part. I have a part of the program that sends out formated data via RS232. I found that the contend of the formatted message is partially distorted partially in an unrecognized way thus the whole message was not right.
if I reprogram the same .out file via JTAG, then the problem goes away.
I checked the flash API version i believe both of them are version 210 which is the latest for 28335. Can any one shed light on what might have gone wrong in the process?
Thanks
Leong
Hi Leong (from AV?),
This is just a guess, but I remember reading that when you use a peripheral to boot the associated registers are not in the same state as when the DSP comes out of reset. I would look into your SCI initialization function and make sure that all the registers are properly initialized.
Samuel
Hi Sam how are you. Thanks for the tip. I was doing a full power recycle after loading the program from serial sdflash. So the only explanation I can have is that jtag and serial flash interpreted some part of the .out file differently to result different image being burned on to the flash. I will look into what you mentioned and also the .cmd file. I also tried to use the codeskin after converting the .out to intel hex, got some warnings that may have indication of improper linker command file lines. But everything worked fine with jtag so i'm puzzled.
Leong
Code Composer allows you to save memory to binary files. If you suspect the image is different between loading with SPI and loading with JTAG then you might save a binary image of the memory in each case. You can then use a binary compare utility to see if differences exist. In windows you can use comp file1 file2 from the command line.
John
Leong,
John is correct. Comparing your memory dumps under different flash programming methods should throw more light and would help you figure out the problem.
Regards,
Manoj