CC1312R7: update throught serial port, modify BIM or modify bootloader.

Hi Javier,

Let me come back to you with some answers today.

Regards,

Arthur

Thank you arthur, after working a bit with with this port Im finding some problems:

• There are some functions for logging but I dont see how to use them with UART or RTT.
• I flash the MCU boot basic proyect erasing all flash with code composer and later I flash the device in 0x56000 with mcuboot_blink(which I suposse is the example applicacion project.) but it doesnt seem to work.

Is there any tutorial or guide to start with this projects?

Hi Javier,

On top of the project's README.md, we have a user guide in some of our stacks: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_10_01_24/docs/ble5stack/ble_user_guide/html/oad-mcuboot/mcuboot.html#mcuboot-overview

For logging, you need to disable the EXCLUDE_TRACE symbol, by for instance appending "x" to it in the project settings:

After that, you need to copy the itm_private.h, trace.c and trace.h files from SDK_PATH\source\third_party\mcuboot\boot\ti\source\mcuboot_app\mcuboot_config to the mcuboot_config folder of the mcuboot_app project.

Last, add the Power driver to SysConfig:

Which file are you flashing at address 0x56000? It should be the .bin file that has been generated in the mcuboot_blinky post-build step.

Regards,

Arthur

Also, it is likely that you get a compiler error about size:

mcuboot_cc13x2x7_cc26x2x7.cmd", line 87: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment fails for section ".text" size 0x4694.  Available memory ranges:

In which case, you have to edit mcuboot_cc13x2x7_cc26x2x7.cmd and modify #define FLASH_SIZE 0x4000 to another value, 0x5000 for instance.

Regards,

Arthur

After doing this changes something weird happens, im able to get the program compiled without problems and within memory range but I get the next error while trying to make it run:

Cortex_M4_0: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.

which is weird because only changed the flash and I think is well inside flash space.

ok, it was because it was out of memory, just expanding the sector was not enought, upper limit its fixed (FLASH size) so if someone has to go thought something similar:

1-reduce primary or secondary sectors size and change start address of each sector accordingly.

In my case I calculate it like this:

2-Change sector map in the program as well in flash_map_backend.h

EDIT:

Also for CC1312R7- LPI had to change:

1 - ITM_3000000 to ITM_115200 in trace.c

2 - IOCPortConfigureSet(IOID_13, IOC_PORT_MCU_SWV, IOC_STD_OUTPUT) to IOCPortConfigureSet(IOID_18, IOC_PORT_MCU_SWV, IOC_STD_OUTPUT); in trace.c

And change the connection in the target configuration in the ccxml to 2-pin advance modes and aux com is UART port., them open the Tools->Code Analysis->Event Analysis and configure for message logging.

Thank you, I will open a new thread for further questions to avoid deviating this thread,

;

Hi Javier,

Looking at trace.c, it seems we configure the output DIO to be IOID_13, which is on the LP-CC1312-R7 connected to BTN-2.

Let's fix that and instead output it to DIO3, which is connected to the "TXD" header of the Launchpad, and thus RXD from the LP-XDS110-ET.

Then, in the same file, we see the speed is configured to 3000000 bits/s (ITM_3000000).

With this information, and this fix, we can now output our trace logs from mcuboot.

Regards,

Arthur

Ok, now after the changes done main bootloader works as expected with this changes.

Now Im in the process of changing the sectors to a size of 0x55000, to do so with the example provided I changed the flash map.h of the booloader to:

    #define BOOTLOADER_BASE_ADDRESS             0x000AA000
    #define BOOT_BOOTLOADER_SIZE                0x5F50//(0x80) removed to make space?

    #define BOOT_PRIMARY_1_BASE_ADDRESS         0x00000000
    #define BOOT_PRIMARY_1_SIZE                 0x00055000

    #define BOOT_SECONDARY_1_BASE_ADDRESS       0x00055000
    #define BOOT_SECONDARY_1_SIZE               0x00055000

and in the post-process steps of the blink project I changed the  step:

sign --header-size 0x80 --align 4 --slot-size 0x56000 --version 1.0.0 --pad-header --pad  to 

sign --header-size 0x80 --align 4 --slot-size 0x55000 --version 1.0.0 --pad-header --pad 

with its .cmd to;

#define FLASH_BASE              0x00000080
#define FLASH_SIZE              0x55000
#define RAM_BASE                0x20000000
#define RAM_SIZE                0x24000
#define GPRAM_BASE              0x11000000
#define GPRAM_SIZE              0x2000

Then I do as with the example, flash the bootloader with code composer erasing the flash and then flash the blinky in 0x55000 in uniflash but the bootloader doesnt start after flashing the blink, If blink is not flashed the bootloader works and outputs data as expected with the previous changes done.

well, after several tries i made it work but in a very weird and not practical way for a application:

first I selected erase all unprotected sectors and debugged the MCUBoot base program, ok blinking and debugging as expected.

Then with Uniflash I write the blink program in 0x55000 and nothing happens, Im not able to make it work.

But if I debug the blink program (selecting to only write the program) and writes it in the sector starting in 0x0000 and up, then everything starts to work.

[39m[INFO][MCB ]: mcuboot_app
[39m[INFO][MCB ]: Primary slot: Image not found
[39m[INFO][MCB ]: Secondary slot: version=1.0.0+0
[39m[INFO][MCB ]: Booting image from the secondary slot
[39m[INFO][MCB ]: bootRsp: slot = 0, offset = 55000, ver=1.0.0.0
[39m[INFO][MCB ]: Starting Main Application
[39m[INFO][MCB ]: Image Start Offset: 0x55000
[39m[INFO][MCB ]: Vector Table Start Address: 0x55080
[00][39m[INFO][APP ]: blinky_app hdr=0
[39m[INFO][APP ]: blinky_app ver=255.255.65535.-1[ÿ

If I write first the blink program and then with code composer I debug the bootloader the bootloader detects it but doesnt start:

[00][1B][39m[INFO][MCB ]: mcuboot_app
[1B][39m[INFO][MCB ]: Primary slot: Image not found
[1B][39m[INFO][MCB ]: Secondary slot: version=1.0.0+0
[1B][39m[INFO][MCB ]: Booting image from the secondary slot
[1B][39m[INFO][MCB ]: bootRsp: slot = 0, offset = 55000, ver=1.0.0.0
[1B][39m[INFO][MCB ]: Starting Main Application
[1B][39m[INFO][MCB ]: Image Start Offset: 0x55000
[1B][39m[INFO][MCB ]: Vector Table Start Address: 0x55080

Any idea?, Obviously I need a reliable way to reset and start the program,

Hi Javier,

Given that you have updated the slot size, you also need to update the imgtool post build command in the post build steps of the mcuboot_blinky project:

So in your case, it will most likely be 0x55000

Regards,

Arthur

Already done as said in the previous post.

and in the post-process steps of the blink project I changed the  step:

sign --header-size 0x80 --align 4 --slot-size 0x56000 --version 1.0.0 --pad-header --pad  to 

sign --header-size 0x80 --align 4 --slot-size 0x55000 --version 1.0.0 --pad-header --pad 

Ok, I was able to make it work changing the address of Flash Vector Table to 0x000AA000, now bootloader program works fine but I´m not able to make it work in the secondary sector.

This is the log If the image is writen in the secondary sector, bootloaders detects it and I guess tries to run it hanging:

[00][00][1B][39m[INFO][MCB ]: mcuboot_app[1B][0m
[1B][39m[INFO][MCB ]: Primary slot: Image not found[1B][0m
[1B][39m[INFO][MCB ]: Secondary slot: version=1.0.0+0[1B][0m
[1B][39m[INFO][MCB ]: Booting image from the secondary slot[1B][0m
[1B][39m[INFO][MCB ]: bootRsp: slot = 0, offset = 55000, ver=1.0.0.0[1B][0m
[1B][39m[INFO][MCB ]: Starting Main Application[1B][0m
[1B][39m[INFO][MCB ]:   Image Start Offset: 0x55000[1B][0m
[1B][39m[INFO][MCB ]:   Vector Table Start Address: 0x55080[1B][0m

And If the same .bin image is writen in the primary sector outputs this log and works fine showing the blinking:

[00][00][1B][39m[INFO][MCB ]: mcuboot_app[1B][0m
[1B][39m[INFO][MCB ]: Primary   slot: version=1.0.0+0[1B][0m
[1B][39m[INFO][MCB ]: Secondary slot: Image not found[1B][0m
[1B][39m[INFO][MCB ]: Booting image from the primary slot[1B][0m
[1B][39m[INFO][MCB ]: bootRsp: slot = 0, offset = 0, ver=1.0.0.0[1B][0m
[1B][39m[INFO][MCB ]: Starting Main Application[1B][0m
[1B][39m[INFO][MCB ]:   Image Start Offset: 0x0[1B][0m
[1B][39m[INFO][MCB ]:   Vector Table Start Address: 0x80[1B][0m
[00][1B][39m[INFO][APP ]: blinky_app hdr=0[1B][0m
[1B][39m[INFO][APP ]: blinky_app ver=1.0.0.0[1B][ÿ

Any idea?, I guess I will be something related to the memory map or the header, but its strange because the booloader detects the image header just fine.

After looking at the documentation I´ve been able to run the image in the secondary sector changing the .cmd config to  this:

#define FLASH_BASE              0x00050080
#define FLASH_SIZE              0x50000-0x080
#define RAM_BASE                0x20000000
#define RAM_SIZE                0x24000
#define GPRAM_BASE              0x11000000
#define GPRAM_SIZE              0x2000

/* Export the header address to the blinky app */

MCUBOOT_HDR_BASE = 0x00050080;

Now, what puzzles me is why the example works flashing it in the 0x56000 address when the .cmd config points to flash in the primary sector (0x00).

Hi Javier,

There must be an explanation to that somewhere. Let me come back to you later today on that.

Regards,

Arthur

any news?