Stellaris ROM UART Bootloader Question

Instead of using (*((void (*)(void))(*(unsigned long *)0x2c)))(), I also tried ROM_UpdateUART(). The sniffer show no response/transmit from Stellaris ROM.

On the PC, I also used LM Flash programmer Build 1588 with manual configuration, serial UART interface, 115200, disable auto baud, program address offset 0.

The serial sniffer shows the PC sent "03 20 20". This doesn't make feel good since LM flash Programmer and sflash data protocol is not even the same. There is no response from Stellaris ROM at all.

Thanks,

Dennis

Dennis,

This post has a good explanation of where the 0x2C comes from. I will investigate what significance the 0x51 has and whether LMFlash communicates differently from sflash.

As for the ROM_UpdateUART function, it requires UART0 to already be configured and running before it is called. Is this the case for your calling program?

Hi,

To eliminate all variables, I decided to use dk-lm3s811 boot_demo2 for the target. The only thing I changed were setting the target to LM4F232H5BB and the internal clock source instead of the external 6MHz. On the PC, I tried both sflash.exe and LM Flash Programmer build 1588. The sniffer shows sflash.exe and LM Flash Programmer build 1588 sent the same packets as I mentioned in the earlier posts. The sniffer shows no response from LM4F232H5BB.  Do you have any working boot_demo2 LM4F232H5BB equivalent that I can try?

Thanks,

Dennis

Both feel & read your pain.  That 232H5BB MCU you reference is the very early, BGA version.  We had that board & its much more popular - and later - QFP version. 

You seem methodical - we wonder if the ROM version of that early MCU might have some limitations.  And - it appears almost "painful" for you to acquire more such devices - should that be your goal.  Finding that BGA MCU - and/or that original Eval board may be difficult - even for the factory.

Might it be easier - and more productive - for you to continue your experiments with more popular & more available boards/MCUs?  At the minimum - this eliminates any, "single MCU anomalies" which can "eat" time & effort...

Dennis,

The LM4F232 versions of boot_serial, bootdemo1, and bootdemo2 can be found in TivaWare\examples\boards\ek-lm4f232. These were not present for the LM4F232 in StellarisWare, but were added in the TivaWare release.

The 0x2C entry point for the bootloader is for flash based bootloaders, such as boot_serial. The call to enter 0x2C will not work unless you have a bootloader flashed into 0x0. Then the boot_demo2 application should be flashed into 0x2800.

If you want to use an application other than boot_demo1 or 2, you will have to modify your linker settings to start the program at 0x2800. The boot_demos have already been modified in this manner. This thread has more detail of how exactly to do this.

LMFlash and sflash use the same data transmission format.

The byte format of your DOWNLOAD_COMMAND packet is

[# of data bytes in packet+2]

[packet data checksum byte]

[command data byte]

4x[program address data byte]

4x [program size data byte]

So your packet data checksum is 0x21+0x00+0x02+0x5E+0xD0=0x51 (byte overflow is ignored).

The "03 20 20" sequence you are seeing from LMFlash is a ping packet to check if the bootloader is present and responding.  The format s

[# of data bytes in packet+2]

[packet data checksum byte]

[command data byte]

The expected reply from the bootloader is a 0xCC ACK byte. You can see the other packet command codes and formats in TivaWare/boot_loader/bl_commands.h

I have verified that calling sflash with the -d parameter does not send the ping command before sending the download command packet.

Since your program was jumping to a non-existent flash loader when jumping to 0x2C, the lack of response is unsurprising. The lack of response after calling the ROM_UpdateUART function is not as easily explainable. Are you certain that your clock settings for both the SysCtlClockSet call and UARTConfigSetExpClk were correct and consistent for your board?

Stellaris John said:

Are you certain that your clock settings for both the SysCtlClockSet call and UARTConfigSetExpClk were correct and consistent for your board?

I am currently use UART0 for my command line interface for diagnostic and I have no problem with it. I am using the same FTI RS232 cable and same PC virtual COM port for sflash and LM Flash.

Stellaris John said:

The 0x2C entry point for the bootloader is for flash based bootloaders, such as boot_serial. The call to enter 0x2C will not work unless you have a bootloader flashed into 0x0

I got this from LM4F232 datasheet SPMS328F "For applications that require in-field programmability, the royalty-free Stellaris Boot Loader can act as an application loader and support in-field firmware updates". It did NOT say anything about flash base bootloader is required. My guess is it is what it is today. I will try to get the flash base bootloader working.

This is just like my firmware calling ROM_UpdateUART(). If this is the case, look like the problem is I still have UART RX interrupt enable and the ROM_UpdateUART() never get anything in bl_uart.c UARTReceive().

I will try this but I lock my board because of a bad clock configuration on the flash bootloader. Sorry to switch the topic but I used the LM flash and LM4F232 Eval board (act as JTAG) to unlock my board ny LM Flash OtherUltilities->DebufPortUnlock->Unlock and I could NOT unlock ny board. Any suggestion?

Hi Dennis,

    Select "Blizzard Class", when using the debug port unlock utility.

-kel

Hi,

I have no other FTDI USB my PC and I used DebugPortUnlock->Fury, DustDevil and Blizzard Classes->Unlock and I got this "**ERROR**: Failed to unlock connected device!". Is there anything else I could try?

Thanks,

Dennis

Dennis,

The unlock procedure requires the LM4F232H5BB to be held in reset at the start. Does your custom board have a way of holding the part in reset while you are doing the unlock procedure?

Hi John,

We tried to hold the reset down while power the processor on. My LM4 heated up and my draw about 500mA instead of normal 60mA. I think this board is done. I am going to get another board to have the bootloader going.

Thanks,

Dennis

I disabled UART RX interrupt on my firmware and I still have no UART traffic through ROM_UpdateUART(). I going to bring in dk-tm4c123g boot_serial to my application and troubleshoot. I just want to make sure I am looking the right thing. Is dk-tm4c123g boot_serial bl_main.c Updater() function is the source code for ROM_UpdateUART()?

Thanks,

Dennis

Dennis,

The bl_main.c Updater runs the same code as the UpdateUART() code.

Before you try integrating boot_serial into your application to test it, I recommend you try to get the basic bootloader setup working.

First try the boot_serial combined with the boot demos from the dk-tm4c123g kit. You will have to modify their clocking to fit your crystal and remove the OLED display specific code. If you can verify that the flash bootloader works correctly, you can then modify them to call the ROM bootloader. If you can verify that works with known good code, then you can work on seeing how they differ from how code.

Hi John,

Thank you for your supports. I got my board firmware functioning with ROM_UpdateUART() correctly now. Here are the keys:

1. Even that I am using Stellaris LM4F232H5BB, boot_demo2.c in StellarisWare\boards\dk-lm3s811\boot_demo2 is not working for me. On the other hand, TivaWare_C_Series-2.0.1.11577\examples\boards\dk-tm4c123g\boot_demo2 works with minor modifications.

2. I used ROM_UpdateUART().

3. There are so many TI documents and ways to do this simple task. It is more confusing than it helps but I guess that i swhy TI has E2E forum and FAEs.

4. UART FIFO enable is a requirement. I don't remember to have this information anywhere in TI document but there are so many therefore I might miss it.

5. All other CPU interrupts have to be disable. TivaWare_C_Series-2.0.1.11577\examples\boards\dk-tm4c123g\boot_demo2 has this information. It is critical because our firmware has most of peripheral interrupts enable.

Thanks again.

Dennis

Dennis,

I am happy to see you've got your program running successfully.

I'd like to apologize for not better explaining my directions to use the TivaWare boot demos. The EK-LM3S811 has an old Stellaris part from 2006, so it's not surprising that the LM3S811 code did not run correctly on your board.

The LM4F232H5BB is a Stellaris part, but was renamed to the Tiva TM4C123GH6ZRB. The boot demo applications for that part were added during the StellarisWare to TivaWare conversion. This is why I recommended you use the TivaWare code instead of StellarisWare, even though you have a Stellaris part.

Thank you for your quick inputs and responses, John. We are able to get this working great.

You have a great Friday,

Dennis