TM4C1290NCZAD: Arm-based microcontrollers forum

Hi,

PP_Screen(ui32SysClock) is doing the Flash Erase, Flash Write and Flash Read in the same order specified. SSI interface is used along with FatFs for reading the files from SD card and store into Flash memory.

I just figured out that the after the last step Flash Read operation is causing the issue of modifying the System Clock to 0x00008100 (always)....

Your response and input will be appreciated since we got stuck with this issue and unable to proceed further to implement ROM bootloader.

Hi,

  Can you show your PP_Screen code?

  How are you calling the ROM bootloader? You provided not enough details to diagnose your problem. 

  BTW, it is a US holiday week. Response will be delayed. 

I have nearly 100 files to read from SD card and write into External Flash. I am using SSI interface to read the files from SD card and write into External Flash using the SSI interface. Also, I was doing the Flash Read operation after every write into the Flash. Earlier I was doing the Flash read operation after completing all the 100 files write operation. I have identified that this Flash read operation was causing the issue to modify the clock value.

To resolve this, I have performed the Flash read operation after every write operation into Flash. With this update, the clock value is not getting modified and it is stable.

Now, Please guide me how to use the ROM_Bootloader in the similar fashion of reading the firmware.bin from SD Card and load into Internal Flash. Can I use the Internal Flash write API calls to load the firmware file into Internal Flash(onchip).

Please confirm the name of the firmware .bin file to be placed in the SD card for the ROM_Bootloader to read the file through SSI Interface. I know that SSI0 need to be used for the boot loader.

Ram V said:

To resolve this, I have performed the Flash read operation after every write operation into Flash. With this update, the clock value is not getting modified and it is stable.

Glad you resolve the issue with a solution.

Ram V said:

Now, Please guide me how to use the ROM_Bootloader in the similar fashion of reading the firmware.bin from SD Card and load into Internal Flash. Can I use the Internal Flash write API calls to load the firmware file into Internal Flash(onchip).

I think I'm not clear with your application. Your application description so far seems to read some files from SD card through the SSI interface and then write to the external flash through the SSI interface. is that correct? What are the 100 files you are reading from SD card? Are these firmwares or some data files?

What I don't understand is why the ROM_Bootloader is involved here? Normally you will use either a ROM-based or flash-based bootloader to upgrade your existing firmware on the MCU. Perhaps, I'm missing something, you seemingly want to use a ROM bootloader to read the SD card and then write to the external flash. Is that what you are asking?

 First of all, the MCU ROM bootloader cannot read the SD card. The ROM bootloader can only read from among the interfaces like UART0, SSI0, I2C0, USB, or EMAC. Refer to Bootloader user's guide about ROM-based bootloader in section 2. https://www.ti.com/lit/pdf/spmu301

Please find the design of the required application.

SD card is interfaced through SSI0 with the specified MCU. SD card will have the file "firmware.bin" which is the new application firmware file to be updated into the onchip Flash. I understand that ROM Bootloader can use the SSI0 interface to update the firmware.

My application is already interfaced to access the firmware.bin from SD card using SSI0. Under certain condition, my application will decide to invoke the ROM_UpdateSSI() function to update the firmware. I understand that ROM_UpdateSSI() function will transition to boot loader mode and erase the onchip MCU flash and then program with the new firmware by reading among the interfaces like UART0, SSI0, I2C0, USB, or EMAC.

.Boot Loader.docx

The ROM_UpdateSSI implements the Serial Update as described in section 5 of the bootloader user's guide. Go through the Packet Handling and the Transport Layer protocol for SSI Transport. The ROM_UpdateSSI cannot support/handle a FAT filesystem to read files that is stored in the SD card. You will need to customize your own flash-based bootloader. Again, go through section 5 as this is the protocol for packet handling between the MCU and the host. Beyond what is offered in TivaWare SDK, you will need to customize for your application. 

I understand that ROM bootloader will not suits to my application.

Now, please guide me on how to proceed to implement the Flash bootloader for requirement.

My requirement is to upload/update the firmware.bin stored in SD card which is interfaced with MCU through SSI2 and upon shorting a GPIO pin, the bootloader has to be invoked and should upload the firmware.

I have looked at the two examples - boot_demo1 and boot_serial and updated bl_config.h file as per my requirement.

boot_demo1 is the application code should take care of detecting the SW1 switch and upon detecting it, bootloader should be invoked.

Also, boot_serial is providing various interfaces in which I have enabled SSI related interface in bl_config.h...

Now, where to add the SD card file reading functions in my project.

6165.bl_config.h

Ram V said:

Now, where to add the SD card file reading functions in my project.

Hi,

  You are free to modify the bootloader. Please look at Updater() function and other related functions in the bl_main.c file. Updater() function is used to update the firmware of the selected port. See if you plug your own hook functions to access the SD card. How you want to customize the bootloader to make it work with a SD card is all up to you.

Thanks for the details. 

I have an important question before integrating my SD card code.

I understood that JumpToBootLoader() should be invoked from my application after detecting switch press or other event as per my wish.

But I have looked at the code of jumping to boot loader.

void
JumpToBootLoader(void)
{
//
// We must make sure we turn off SysTick and its interrupt before entering
// the boot loader!
//
MAP_SysTickIntDisable();  // Systick are disabled!!! which are required for my FatFs
MAP_SysTickDisable();     // Systick are disabled!!! which are required for my FatFs

//
// Disable all processor interrupts. Instead of disabling them
// one at a time, a direct write to NVIC is done to disable all
// peripheral interrupts.
//
HWREG(NVIC_DIS0) = 0xffffffff;
HWREG(NVIC_DIS1) = 0xffffffff;
HWREG(NVIC_DIS2) = 0xffffffff;
HWREG(NVIC_DIS3) = 0xffffffff;

//
// Return control to the boot loader. This is a call to the SVC
// handler in the boot loader.
//
(*((void (*)(void))(*(uint32_t *)0x2c)))();
}

-------------------------

To access my SD card using FATFs, I must require Systick calls enabled since FatFs requires disctimerproc() is called under 10ms callback to make the FatFs to work in order to access the SD card file. But JumpToBootLoader() disables the systick calls as shown above. Then how it is possible for me to access the SD card?

Also, please suggest me any alternate ways to access the files present in SD card.

Next thing is: How can I modify the Updater() ?

1) Updater() function is having a switch statement with values of g_pui8DataBuffer[0] such as COMMAND_PING to perform some operation. What is the use of these commands?

2) Should I need to store the SD card file contents into g_pui32DataBuffer?

3) The maximum supported size is 65 which means I can send maximum of 65 bytes at a time from SSI interface?

Ram V said:

o access my SD card using FATFs, I must require Systick calls enabled since FatFs requires disctimerproc() is called under 10ms callback to make the FatFs to work in order to access the SD card file. But JumpToBootLoader() disables the systick calls as shown above. Then how it is possible for me to access the SD card?

Also, please suggest me any alternate ways to access the files present in SD card.

Disabling application interrupts is to ensure the processor can successfully jump to the bootloader from the application. Think what happens when you jump to to the bootloader and there is an application interrupt like PWM, I2C, UART or any peripheral. Or just before you are able to jump to the bootloader, there is a asynchronous peripheral that just come in. Once you are in the bootloader, it does not have the capability to handle any interrupts. If you must keep a certain interrupt then you need to create a vector table and a ISR to handle the interrupt. I have not come across a bootloader that still needs to handle an application interrupt so this is only a suggestion. You need to figure how to handle it based on the explanation I provided. Again, you are designing a custom bootloader, you can do things that you think fit for your application. 

Ram V said:

1) Updater() function is having a switch statement with values of g_pui8DataBuffer[0] such as COMMAND_PING to perform some operation. What is the use of these commands?

I have said several times that the serial bootloader (SSI, UART, I2C) uses a custom protocol to download the firmware. The commands are described in the user's guide. The host software may issue COMMAND_PING to interrogate the presence and the wellbeing of the client. Please also refer to this serial bootload app note which will help. Although it is for UART bootloading but the concept can be reused, https://www.ti.com/lit/pdf/spma074

Ram V said:

2) Should I need to store the SD card file contents into g_pui32DataBuffer?

3) The maximum supported size is 65 which means I can send maximum of 65 bytes at a time from SSI interface?

I tend to think it will be less effort if you reuse as much as possible the existing code. If you must modify the size and any other changes in order to build your custom bootloader you are free to do so. Sorry, we have no such experience with a bootloader for SD card and this is all I can suggest.