- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
I have been trying to use the "serial_flash_programmer" included in controlSUITE (controlSUITE\device_support\~Utilities\serial_flash_programmer) and have had some success.
I had to recompile it with visual studio, but serial_flash_programmer.exe runs fine now.
For the Flash kernel, I am using f28035_flash_kernel (controlSUITE\device_support\f2803x\v129\DSP2803x_examples_ccsv5\f28035_flash_kernel). I had to make some minor modifications. In Shared_Boot.c, the code was erasing only sectors A-D so I modified it to erase all flash sectors of an F28035
status = Flash_Erase((SECTORA | SECTORB | SECTORC | SECTORD | SECTORE | SECTORF | SECTORG | SECTORH), &FlashStatus);
Anyway, I am able to successfully load my code via:
serial_flash_programmer.exe -d f2803x -k f28035_flash_kernel.txt -a myapp.txt -p COM20 -v
at the default 9600 baud. My code (myapp.txt) is an ascii file generated by hex2000 in boot rom format, and is about 180KB.
The Kernel AutoBaud is successful, then the kernel loads and boots. Then I get a message saying Application AutoBaud is successful and then it seems to hang.
After about 1 hour, it completes and says "Application Load Successful".
Why is this taking so long?
I tried increasing the baud rate to 115200, but autobaud would not lock (and it didn't work at 57600 either), so I had to use 38400 and that seemed to work but it still took about 20-25 min.
serial_flash_programmer.exe -d f2803x -k f28035_flash_kernel.txt -a myapp.txt -p COM20 -b 38400 -v
This is just a guess, but I think it may be taking so long because of the checksum. But still, my application is only 180KB, I am not sure why this is taking so long.
I know C2Prog is an alternative but it doesn't work for my application because it uses 38400 to load the kernel, and then 115200 to transfer the application. I am using a Bluetooth module to do the serial communication and the BT module only works at one programmed baud rate, so I can't really use anything that's switching baud rates around. This is why I chose to investigate the serial_flash_programmer which seemed perfect for my application. I am sure that the BT module communicates correctly because when my application is running, I can successfully communicate through SCI via the BT module.
Hello Dan,
I am using Windows 10 and I see the same happen (I get a COM3 and a COM4) when I connect to a Bluetooth module. I tried COM3 and that didn't work, but when I tried COM4 it worked perfectly.
When I check bluetooth options under COM ports, I see the following.
If you are using the outgoing SPP Dev port, the serial_flash_programmer should work fine even though it says "outgoing". I was able to use it successfully.
I believe the outgoing/incoming simply indicates which device initiates the connection first. In your case it is the PC, so I would use the "outgoing" port your COM5.
I looked up the module you are using (sparkfun) and it seems some people have had issues because the TX and RX pins were reversed so make sure that is correct.
Hi Fulano,
Thanks very much for the help. I think that I have the BT module connected because it shows that "Kernel Loaded". However, it met a problem that after it shows "Application AutoBaud Successful", then serial programmer exits without printing any error and the program is not burned into the unit.
Have you ever met similar problem?
Regards,
Dan
