TMS320F28377D: I can't get get the bootloader to work using C2000ware provided code

Philip, 

Please take a look at the SCI Flash Kernel Application Note: https://www.ti.com/lit/an/sprabv4d/sprabv4d.pdf

When setting the boot mode select pins, the boot mode in ROM is set to go to the SCI Bootloader. The SCI Bootloader in ROM is separate from the Flash Kernel project you are referring to above. The SCI ROM Bootloader can be used to download the SCI Flash Kernel project. The serial_flash_programmer utility in C2000Ware (utilities > flash_programmers>serial_flash_programmer) can be used to download the Flash kernel to RAM. To download the flash kernel, you would need the project to be formatted by the hex2000 utility you mentioned. 

Once the flash kernel is running, it communicates to the serial_flash_programmer utility by sending and receiving the packets you are referring to in your screenshot. The user can send commands to the Flash kernel such as programming an application into Flash, erasing Flash, etc. The command is put into a packet and sent to the kernel when then parses the packet and then executes the command. 

The guide you linked is also for another line of devices. For more information on the F2837xD devices, please refer to the following: https://www.ti.com/lit/ug/spruhm8i/spruhm8i.pdf 

Thanks, 

Anu

I just mentioned that your SCI Flash Kernel project is wrong.  I was showing where in the code on that project that it doesn't match the hex files that you make with hex2000.  You're asking me to do something that I told you I did and found a flaw in your code project

If I am missing the SCI ROM bootloader on my custom hardware, how can I put it onto the device?

Philip, 

The ROM bootloaders should already be present in your device. 

The hex files that are used by Flash kernel are not downloaded right away. The user first needs to enter a command to the kernel, such as DFU. When the command is received in the form of a packet that needs to be parsed in order for the kernel to understand which command it needs to execute. Once it sees that there is a DFU command, it then jumps to the function needed to perform the DFU. It is only at this point that the hex file is read in by the kernel to write to Flash. 

The general flow is as follows:

1. Set the Boot Mode Select Pins to SCI Boot - this will direct the boot sequence to the SCI Bootloader in ROM 

2. Use the serial_flash_programmer utility to download the kernel - The SCI Bootloader in ROM downloads the kernel here, and takes in a hex file in order to do so 

3. Use the kernel to write an application to Flash - this takes in another hex file specifically for the application, but the kernel needs to decode a command from the utility first, and the decoding happens in the function you mentioned above

Thanks

Anu

Yes, and if you consider step 3, the code in the SCI_flash_kernels project is incorrect as shown in my picture above the AA08 doesn't match what is used in the project.  AA08 is the standard start of the file as shown in the pdf I liked so why is this inconsistent?

Philip, 

That function is not supposed to read through a hex file. It is supposed to decode a command from the user which they send through the serial_flash_programmer utility. The SCI_Boot function in SCI_Boot.c is where the hex file starts getting read in. 

Have you had a chance to read through the application note? It will help give you an idea of how the flash kernel functions. The function you are referring to is decoding the packet described in Section 5.1. 

Please give the application note a read through, if you have questions about it let me know. 

Thanks,

Anu

That would make sense. but try to run the serial flash programmer example.  It doesn't prompt the user for a command until after it loads the software.  So what you are saying doesn't make sense.  It directly reads from the hex file first.  Run the example in serial flash programmer and tell me how it asks for a command before it runs the GetPacket function. This is evident specifically in Get_function in SCI_GetFunction.c line 173 which shows it tries to read a packet that gets sent from the hex file in serial flash loader before prompting to use a command on line 175.

Philip, 

Philip Manning said:

This is evident specifically in Get_function in SCI_GetFunction.c line 173 which shows it tries to read a packet that gets sent from the hex file in serial flash loader before prompting to use a command on line 175.

The kernel waits in the SCI_GetPacket function while the host utility is prompting the user to enter a command. It does not exit the function until the user has sent a command. Once the user enters the command, the host utility creates a packet and sends it to the kernel. I am not sure what you are referring you when you say "Get_function", there is no such function.

If you look inside SCIA_GetOnlyWordData, the function being called at line 584 in SCI_GetFunction.c, you will see that there is a while loop that the kernel is waiting in. The condition of that while loop is only fulfilled when there is something in the RX Buffer for the kernel to read. This will not be the case until the host utility sends a packet. The host utility will not send a packet until it has received a command from the user. So there is no way the kernel is reading in another hex file in the SCI_GetPacket function. It is waiting for a packet from the host. 

Have you read through the application note? Have you also tried running the example on a ControlCard? The details of the kernel implmentation are explained in the application note, the questions you are asking can be answered by reading it and running the example on a ControlCard to get a feel of how the kernel operates. 

Thanks, 

Anu