TM4C123 hard fault when bootloader is erasing flash with BLInternalFlashErase()

Hello Jarret,

The Page Size and the Flash size are different on the two devices. Have you done the mapping correctly. As I see the BL at 0x3F000 does not make sense as it would be residing at the end of the Flash and if the App is corrupted the device will not have a method to enter the boot loader.

Regards
Amit

Hi Amit,

Thanks for your quick reply.

The bootloader residing at the end of flash has the drawback you described, but is separate from the issue at hand.

I can't explain why single stepping the code results in correct behavior for the BL erasing the app flash space but free running the code causes a hard fault. It looks like the ProgramCounter gets loaded with 0xFFFF.FFFE at some point in the process, but I can't reproduce it through debugging b/c of the code stepping behavior described.

For the TM4C123 I have the flash configured as follows in the respective *.cmd files:
App: 0x0-0x3C000 (map shows 0x5026 used)
BL: 0x3D000-0x3E000 (map shows 0x784 used) - this start address is different than described above since there was potential for the BL to exceed the 256KB flash boundry when it was defined at 0x3F000 above.

I have the FLASH_PAGE_SIZE defined as 0x400 (1024B) for both the TM4C123 & TM4C129 in the respective bl_config.h files.

Thanks,
Jarrett

Hello Jarrett,

OK when the fault does occur, did you check what is the NVIC_FAULTSTAT and NVIC_FAULTADDR values?

Regards
Amit

Hi Amit,

NVIC_FAULTSTAT = 0x1 (Instruction access violation) - thus BFAULTSTAT=0x0 (not a valid addr in FAULTADDR)
NVIC_FAULTADDR = 0xE000EDF8

I tried to use the 'Diagnosing Software Faults in Stellaris® Microcontrollers' app note without much success since I didn't know where to go with a FAULTSTAT = 0x1.

-Jarrett

Hello Jarrett,

The normal rule of thumb was to have the BL at 0x0 and APP code at next page boundary after the BL. Since this is something different, can you share your CCS project and also indicate which TivaWare release is being used?

Regards
Amit

Hello Chester,

Only if the code execution is >40MHz. The default boot loader does not go above 40MHz. But having said that if the user has modified it for >40MHz, then this could be a likely issue

Regards
Amit

Amit Ashara said:

Only if the code execution is >40MHz.

Agreed. The CPU frequency when the bootloader suffers the hard fault is not currently mentioned, so further information is required to determine if MEM#14 is the cause of the failure.

The other comment I have just noticed is that the hard fault doesn't occur when the same bootloader is used on a TM4C129, and MEM#14 only affects TM4C123.

Hello Chester,

Yes, that is true. it is supportive of the TM4C123 errata. But then having page size of 0x400 means that TM4C129 is working harder to run Flash Erase on the same page till the actual page boundary is reached. These were some of the things that we did correct on Release 2.1.1.71

Regards
Amit

Thanks for the input and suggestions.

I'll try the suggestions and update next week.

-Jarrett

When the bootloader copies and runs out of SRAM (using the default 'bl_startup_ccs.s' file), the bootloader does not go into hard fault during the memory erase/copy process.

BTW - my BL is now located at 0x0 and the app is located at 0x4000.

Hello Jarrett,

If the boot loader is from 0x0 to 0x3FFC then it will not run of SRAM. Even with the updated settings are you getting a Bus Fault?

Regards
Amit

Hi Amit,

I am using the TivaWare 2.1.1.71 BootLoader straight out-of-the-box with the exception of a modified linker file (bl_link_ccs.cmd) to adjust the FLASH & SRAM sizes to 0x3000 & 0x8000 respectively for the TM4C123 part. Looking at the *.map file, 0x07BC of the flash is used for the BL.

I am jumping to the BL from my application to start an application update. Since my BL is residing at address 0x0, I jump from my application to address 0x2C (as defined in bl_startup_ccs.s to get to the UpdateHandler).

From what I can tell the UpdateHandler in bl_startup_ccs.s does 3 things in my implementation (no special initialization hooks or re-init hooks):
1. calls ProcessorInit
2. loads the SP
3. calls Updater (in bl_main.c) to handle the SPI communication

From what I can understand, the first thing ProcessorInit does is copy the BL from its flash address of 0x0 to the start of SRAM at 0x2000.0000.
It looks like it does some data zeroing, changes the vector table pointer, sets the code to run from 0x2000.0000

Is my understanding of this process incorrect?

Thanks,
Jarrett

Hello Jarrett

Yes, that is correct. However what is not correct is the FLASH size being mentioned as 0x3000. On TM4C1294 the flash bank size would be 0x4000

Regards
Amit

Thanks!
I'll be sure to update the bootloader size for the TM4C129 part since the flash page size is 0x4000 on that part.

Side question related to the TM4C129 part:
If I define the BL to reside from 0x0000-0x4000, can I define my application to reside starting at 0x4000, or do I need to leave a blank page in between and start at 0x8000?

Thanks,
Jarrett

Hello Jarrett

Yes, you can have the application starting at 0x4000. There is no requirement from the boot loader side to have an empty sector. Do make sure that the boot loader cmd file is told that it has a Flash of 0x4000 so that it does not "mistakenly" put something outside the range into the application range.

Regards
Amit