TM4C129XNCZAD: How to extend the bootloader space in flash memory ?

Hi Ray,

ray yang said:

using the bootloader to download the application, the device will be re-powered,

it will not jump to the application side, I don't know where the reason is.

I don't really see a problem with your configuration for 0xC000. What do you mean the device is re-powered? Do you mean the device is reset?

Can you check a few things.

 1. After the application is loaded, can you still connect to the device?

 2. If you can connect to the device, can you look at the content of 0x0. Do you see the bootloader code there?

 3. Do you see the application code at 0xC000. You can view the content of the memory by opening the Memory Browser window.

 4. Did you use dfuprog.exe to program the application? 

 5. Can you use your custom bootloader to load a simple non TI-RTOS program at 0xC000. Try a simple program like the blinky. Will the bootloader jump to the blinky (starting at 0xC000) and start to blink?

 6. Before you change to 0xC000, the default is 0x4000. Does your bootloader work when it was less than 0x4000?

bootloaderusb_23Jun2022.zip

hello_world_23Jun2022.zip

Hi Charles,

In fact, what I want is for the bootloader to occupy 128Kbtes of flash memeory space.

I recreated a bootloader and an os-less application,
the application is extremely simple, triggering the GPIO continuously.

The bootloader space is divided into 128KBytes (0x20000), and the LM Flash Programmer utility (build 1613) is used to burn in the bin files, then the application does not work, even if I power off and power on the board again.

Ray Yang

Hi Ray,

  Please check the return value of  CheckForceUpdate. It looks like you have setup the PP4 pin for force update. If CheckForceUpdate returns a 1, then it will jump to the UpdaterUSB rather than the application.

ResetISR: .asmfunc
;;
;; Enable the floating-point unit. This must be done here in case any
;; later C functions use floating point. Note that some toolchains will
;; use the FPU registers for general workspace even if no explicit floating
;; point data types are in use.
;;
movw r0, #0xED88
movt r0, #0xE000
ldr r1, [r0]
orr r1, r1, #0x00F00000
str r1, [r0]

;;
;; Initialize the processor.
;;
bl ProcessorInit

;;
;; Call the user-supplied low level hardware initialization function
;; if provided.
;;
.if $$defined(BL_HW_INIT_FN_HOOK)
.ref BL_HW_INIT_FN_HOOK
bl BL_HW_INIT_FN_HOOK
.endif

;;
;; See if an update should be performed.
;;
.ref CheckForceUpdate
bl CheckForceUpdate
cbz r0, CallApplication

;;
;; Configure the microcontroller.
;;
.thumbfunc EnterBootLoader
EnterBootLoader:
.if $$defined(ENET_ENABLE_UPDATE)
.ref ConfigureEnet
bl ConfigureEnet
.elseif $$defined(CAN_ENABLE_UPDATE)
.ref ConfigureCAN
bl ConfigureCAN
.elseif $$defined(USB_ENABLE_UPDATE)
.ref ConfigureUSB
bl ConfigureUSB
.else
.ref ConfigureDevice
bl ConfigureDevice
.endif

Hi Charles,

I can't figure out why, the whole thing seems unbelievable to me.

First, according to your reply, I turned off the detection of GPIO status ( disable the PP4 pin for force update),
I adjusted the bootloader space to 128Kbytes, and the application was also adjusted accordingly,
After updating the program through the bootloader, it can jump to the application side.

Next, I turn on the GPIO detection state ( enable the PP4 pin for force update), and after updating the program through the bootloader (the space is still 128KBytes), it can also jump to the application side.

Thank you for your feedback, the real reason I have to investigate again.

So far it seems to be working well, the whole thing seems to go around in circles.

Hi Ray,

  很高興聽到你的問題得到解決。

Hi Charles,

原來在這裡講中文也會通, 真是太神奇了。

Ray Yang