TMS320F28035: SCI boot stuck using control card

Hi Hang,

Let me understand your requirements clearly.

Are you trying to do Live Firmware Update (LFU) on F28035? LFU traditionally requires the custom bootloader (what TI calls the SCI Flash Kernels) to be resident in Flash. When the application is running, if the host sends a firmware update command, the APP will receive this command (e.g. over SCI), then transfer control to the SCI Flash Kernel. The SCI Flash Kernel will download the new image, erase and program the Flash. Since there is only 1 Flash bank, the Flash APIs and wrapper functions will need to be run out of RAM. Additionally, if during LFU, you want to continue to run ISRs, those also will run from RAM. When the operation is complete, a device reset can be triggered (e.g. using Watchdog) and then the new firmware will take effect.

All of the above can be done while in Flash boot. In other words, you never have to use SCI boot mode and/or invoke the SCI ROM bootloader.

Best,

Matt

Hi Matt,

The use case would be similar to LFU, or DFU since no "live" features are required. 

As you said, a customized bootloader is also a solution, actually customer already uses bootlader on some devices. But bootloader would take extra memory space. For device that have limited memory space, like F28035, there are no space left for bootloader so they would have to use the SCI boot.

I tried calling SCI boot from APP on other device like F280039 and it can do the job. Now the issue has been reduced to the SCI boot of F28035 EVM. I can't go through the very original SCI boot route of F28035 EVM. 

Regards,

Hang.

Hi Hang,

Thank you for the clarification. You can jump directly to the SCI bootloader in ROM using software, but there are a few things to keep in mind.

Note however that the device may be at a different state when you are calling the SCI bootloader from the application. i.e. the device state (in terms of PLL and WD settings) may be different between invoking the loader after a reset as opposed to invoking it from the application, since your application might have changed the PLL and WD settings. Once you have taken into account the differences, the SCI loader should work as before.

Best,

Matt

Hi Matt,

When you said “work as before”, you mean work as the sci boot example. However, the example doesn’t work from my side.

The first screen shot is taken when I do the example sci boot, with gpio changes. I need help solving the problem in the sci boot example. Not jumping to sci boot from app.

Regards,

Hang

Hi Hang,

I've seen this happen before, but there are a few things I need to check.

1. What hex utility post-build steps are you using to build the app file? 
2. Is the application target config linked for Flash? Are all Flash sections for the application aligned to 128-bit boundaries in the linker command file?
3. Does it still freeze at a lower baud rate?

Best,
Matt

Hi Matt,

I am using the hex2000.exe to generate app hex. I have not checked the app hex yet. I think I am stuck at the stage where the ROM bootloader is copying the flash kernel on RAM. The point I stuck is the final words in the kernel hex. The kernel hex is just the example.

I attach here a screen shot of the kernel hex. It ends with 00 00. And it stucks at the final 00 words.

I also attach the app file here so that you can check the format. It's just the flash_f28035 example.

But again, based on the place where it stuck, I think app hex is not involved yet. Also, if it's a 128-bit alignment issue, we should see a program error from the kernel, but not stuck, right?

I also tested slower buad rate down to 4800, the issue is the same.

Regards,

Hang.

Hi Hang,

Matt is currently out of office for the holidays; please expect a delayed response.

Best Regards,

Delaney

Hi all,

Updating the progress here. 

I switched the serial connector, and I can move on to app autobaud now. Previously I am using the TX/RX on the integrated XDS110 on some other C2000 launchpad and jump it to the dock to the F2803x CC. Now I am using a standalone serial port connector.

However, I stuck again at the app autobaud. The serial flash programmer is stuck at reading the response of the first block, which means it has passed autobaud. But when connecting to the F2803x, I found that the CPU is still waiting for autobaud.

The serial flash programmer thinks it has done autobaud but F2803x does not. 

Regards,

Hang

In case there is more issue in the connect, I attach here a photo of my connection. Perhaps you may help checking if it's correct

Hello Hang,

The expert is out of office until tomorrow, please expect a delay in response.

Thank you

Luke

Hi Hang,

Can you confirm if the F2803x's SCIRX pin (GPIO 28) is being correctly sent the autobaud character ('A') from the host using an oscilloscope? 

Best,
Matt

Hi Matt,

It turns out that it's not stucking at autobaud, instead, it passs the autobuad but reset soon after and goes back to autobaud again.

I looked at the kernel codes, seems it's returning after programing the first block, which is way too early.

the copydata() function is returning at the marked line, and the kernel ends very earily. I commented out all the return statements in this while loop (commented out serveral more in other if-else branches), and I can run the SCI boot now.

It seems to me this is a fatal BUG of the kernel example, would you please help looking into it?

Since I can run the SCI boot example now, I start to initiate an SCI boot from a APP, I used the below codes to jump back SCI boot in ROM:

I looked up the address of ROM SCI boot in the TRM and jump to it using pointer. However, the issue in my first post happened again(see picture in first post). The serial flash programmer is stuck waiting for the response of the last byte of the kernel transfer. At this point, the F2803x has pased kernel transfer and enters the kernel already (waiting for autobaud).

Then I simply skip reading the response of the last byte in serial flash programmer like below (here I knew i=2164 would be the last byte):

The the progarmming process works normally, I can flash the APP and run it. But still, skipping the last response is not so reasonable, so I need find the cause of this as well.. 

Any idea what's the problem here?

Regards,

Hang.

Hi Hang,

As mentioned before, the device may be at a different state when you are calling the SCI bootloader from the application. i.e. the device state (in terms of PLL and Watchdog settings) may be different between invoking the bootloader after a reset as opposed to invoking it from the application since your application might have changed the PLL and WD settings. Have you accounted for the differences before calling the ROM SCI boot?

I'll also attempt to replicate the issue on my end as well as loop in the flash kernel expert. I will provide an update by the end of day tomorrow. 

Best,

Matt

Hi Matt,

I copied the code in bootmode_select ROM codes into the app, including the PLL configuration and Watchdog disable, right before jumping ti SCI_boot(). but the issue remains the same.

Is it possible to had an internal online session to discuss on this? I can show and share you the codes.

Regards,

Hang.

Hi Hang,

That sounds good, let's keep the discussion there and update this thread when a resolution is found.

Best,

Matt