TMS320F28335: serial flash programmer

Yes it does. There is a f28335_flash_kernel example which will work with the serial flash programmer. Feel free to select 02x, 03x, 05x, or 06x as your device.

sal

Does this f28335_flash_kernel located at C:\ti\controlSUITE\device_support\f2833x\v142\DSP2833x_examples_ccsv5\f28335_flash_kernel\ folder? Do I need to modify this project and rebuild it?

When I tried to program the F28335, it failed as shown below.

And there was no data transfer between 28335 and PC over serial line.

You should not have to rebuild it.

To help, you can us '-v' for verbose printout.

You need to ensure that your device is booting the SCI boot loader and also that you are using the correct pins to communicate via SCI.

sal

Please see www.ti.com/lit/sprabv4

I can assure that the device is booting in SCI boot mode and the boot pins are right. Because I can program the flash using C2Prog and SDFlash successfully.
I also read sprabv4 documentation, it mentioned that F2833x doesn't have flash API in ROM. Does these flash API involed in f28335_flash_kernel.txt?

Hi Vesgine,

Please try not using the -b option or use -b 9600. It may be that 38400 is too high for boot ROM which is running at 10MHz.

Also, you can use the Visual Studio project to help you debug to see where the serial_flash_programmer is getting stuck. My feeling is that it is stuck trying to perform the autobaud lock. Also, after it is stuck, you can connect to the device via JTAG and CCS and load the boot ROM symbols to see where the device is stuck.

Thanks,
sal

Hi Sal

I have reduced my baud rate down to 2400, but also get the same error. With the same device F28335. Has anybody been successful in programming the F28335 using the serial_flash_programmer? 

Have you attempted the above debugging steps? Can you connect to the device, load symbols and then run the device. When it gets stuck, halt the device and see where the PC is.

sal

Hi Sal

Yes I have loaded the Visual Studio Project. I get past the kernel boot and that is successful as well as the autobaud. To get the autobaud to work I had to move the PurgeComm command in the Visual Studio Project to just after writing to the COM port. But then the code boms out. I have tried to run the CCS Project in parallel and see. Thats where I saw the autobaud is working. But I find it very difficult to get the mistake in the middle of the comms after the autobaud. It looks like the CCS Project stops with a "code abort" and I don't know why?

That is interesting. Are you using the CSM at all on your device?

sal

No the CSM is unlocked, all values are 0xFFFF.

I am using an FTDI USB to Serial Converter

Hi Sal

I have debugged and seen that CSM is unlocked, Flash is erased successfully. But then I get the following error during flash program "FAIL_ZERO_BIT_ERROR"? What does this mean?

Regards

Is this being reported to the serial flash programmer console?

sal

Hi Sal

This is in Code Composer Studio. I have managed to fix this problem. I saw not all sectors of the FLASH are erased in the Code from the Control Suite. Now I gets further but get stuck at error FAIL_ADDR_INVALID. Why this? Has anybody tested these code with the F28335? Or are we suppose to figure it out from scratch?

Could there be something wrong with the .txt file? I used: 

the hex utility arguments look correct.

You may not need the -o option. Can you try removing it and see if it changes the output file.

sal

Are you using CCS to debug? I am not sure why you would be using CCS unless it is for debug.

sal

Hi Sal

Yes Code Composer Studio and Visual Studio. I got it working after making changes to both the CCS project and the Visual Studio Project.

Hi Sal

I am using the CSM now. But now it seems the F28335_kernel.txt does not boot properly when the chip is locked down. Any suggestions?

You have a couple of options, but either way if you want the kernel to work with locked devices, you're going to have to modify the flash kernel CCS project and recompile it:

1. In the flash kernel project, in CopyData() (in Shared_Boot.c), there is a call to CsmUnlock() (in DSP2833x_SysCtrl.c) so change the key in CsmUnlock() to the correct key for the locked device. This means that your device will be temporarily unlocked while programming (and the key will be hardcoded into the kernel and can be easily read).
2. This is more complicated, but more secure.  If you want to keep the device locked while programming and not have to hardcode the key into the kernel, you need to not call CsmUnlock(), and not use the FlashAPI boot ROM symbols library. Instead, use the regular FlashAPI library and store it in secure RAM. That will allow calls to FlashErase and FlashProgram to access the Flash (because it's running from within secure RAM).

You need to re-map the kernel into unsecure memory. The SCI bootloader cannot load code into secure memory since the bootloader is running from ROM and unsecure memory.

sal