Problem loading flash kernel image (TMS320F28377D)

Here the command line I am using (host CPU is running arm linux):
# ./serial_flash_programmer -v -d f2837xD -p /dev/ttymxc1 -b 115200 -k F2837xD_sci_flash_kernels_cpu01.txt -a Tiger1FB_dsp_cpu1.out.txt -m F2837xD_sci_flash_kernels_cpu02.txt -n Tiger1FB_dsp_cpu2.out.txt

The autobaud step works consistently every time for all baud rates.

Hi Robert,

I will look into this Monday morning. Have a good weekend.

sal

Hi Robert,

I don't recall seeing this behavior before.

Do you know what character was sent and what was returned? I would check to see if it was a block address, block size, or block data.

If you cannot find what is causing the problem, I would suggest making a slight code change in the kernel and recompiling it. Hopefully that will get a different .out and then a different .hex which you can try loading.

sal

Hi Sal,

Thanks for the troubleshooting tips. After instrumenting the code on both sides I see that the serial_flash_programmer is always getting 0x0A in response to 0x0D. I added a change to ignore the mismatch to confirm it always happens only when 0x0D is sent (13 total in the file). So this looks like some sort of ascii end-of-line terminater mixup (CRLF=0x0d0a), perhaps in the tty driver on the linux side? I will delve further into this and follow up soon.

Can you confirm that the flash app image for CPU01 is approx 16Kbytes or so? It seems to be taking a long time to transfer the file. Again, this could be due to tty settings on the linux side. About how long should I expect the transfer to take (with TMS echoing each byte) at 115200 baud?

Thanks again,

Robert

Sorry, I meant to say "flash kernel image for cpu01" above. About how large is it supposed to be?

Hi Robert,

I am seeing F2837xD_sci_flash_kernels_cpu01.txt at 50KB. This will take a while to load via the bootloader. There are a number of added features to this kernel that can be removed if you wish to trim down the size of the kernel and the time it takes to load it. The added functionalitymay not be as useful to your application if you are wishing to simply use it as a flash programmer and have no need to unlock the device, or verify the flash image.

The kernel's performance in downloading the flash application is much greater than the bootloader. This is due to a checksum optimization in the communication.

You are probably right about the EOL/CR/LF character. I have seen once before where the individual's serial_flash_programmer was having trouble reading the first character of the hex file properly. But this was strangely on a windows machine, which is the setup we use to do our testing.

You may need to convert the EOL characters for your set-up for the serial_flash_programmer to work properly.

sal

Sal,

I have the flash kernel loading successfully now and am in the process of getting the app download working. Thanks to your help I expect to have it all working very shortly.

The unwanted EOL behavior was indeed due to tty config on the linux side.

One last question: Once I am in the menu (as shown below), what is the correct sequence for programming both CPUs?

Thanks again for your help and patience!

Robert

What operation do you want to perform?
1-DFU CPU1
2-DFU CPU2
3-Erase CPU1
4-Erase CPU2
5-Verify CPU1
6-Verify CPU2
7-Unlock CPU1 Zone 1
8-Unlock CPU1 Zone 2
9-Unlock CPU2 Zone 1
10-Unlock CPU2 Zone 2
11-Run CPU1
12-Reset CPU1
13-Run CPU1 and Boot CPU2
14-Reset CPU1 and Boot CPU2
15-Run CPU2
16-Reset CPU2
0-DONE