Jump from Bootloader to Application

Denis-24

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hi, i've got 2 seperate compiled and linked applications on my TMS570LS3137. The bootloader resides at 0x00000000.

See Linkerfile:

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    FLASH0  (RX) : origin=0x00000020 length=0x0017FFE0
    FLASH1  (RX) : origin=0x00180000 length=0x00180000
    STACKS  (RW) : origin=0x08000000 length=0x00001500
    RAM     (RW) : origin=0x08001500 length=0x00026B00

/* USER CODE BEGIN (2) */
/* USER CODE END */
}

/* USER CODE BEGIN (3) */
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
    .intvecs : palign(32), fill =0xffffffff {} > VECTORS
    .text    : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .const   : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .cinit   : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .pinit   : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

The application resides at 0x00020000.

See Linkerfile:

/*----------------------------------------------------------------------------*/
/* Memory Map                                                                 */

MEMORY
{

/* USER CODE BEGIN (2) */
    VECTORS (X)  : origin=0x00020000 length=0x00000020
    FLASH0  (RX) : origin=0x00020020 length=0x0015FFE0
    FLASH1  (RX) : origin=0x00180000 length=0x00180000
    STACKS  (RW) : origin=0x08000000 length=0x00001500
    RAM     (RW) : origin=0x08001500 length=0x00026B00
/* USER CODE END */
}

/* USER CODE BEGIN (3) */
/* USER CODE END */


/*----------------------------------------------------------------------------*/
/* Section Configuration                                                      */

SECTIONS
{
    .intvecs : palign(32), fill =0xffffffff {} > VECTORS
    .text    : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .const   : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .cinit   : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .pinit   : palign(32), fill =0xffffffff {} > FLASH0 | FLASH1
    .bss     : {} > RAM
    .data    : {} > RAM

/* USER CODE BEGIN (4) */
/* USER CODE END */
}

The jump from application to bootloader is working very fine with

systemREG1->SYSECR=0x0000C000;

But, how can i jump from Bootloader to Application?

over 10 years ago

0 Jean-Marc Mifsud over 10 years ago

TI__Mastermind 22375 points

Denis,

We provide an example of bootloader using SPI, CAN or SCI.

Please have a look at this document:

The code can be downloaded from this link:

Please have a try and let me know.

0 Denis-24 over 10 years ago in reply to Jean-Marc Mifsud

Prodigy 90 points

Hello Jean-Marc,

i have already read that, but i still don't understand how the application (in the application note) was set up.

My last try for jumping into my application was the following codeline:

((void (*)(void))(uint32_t)0x00020000)();

After that the red LED (nERROR) was turned on.

0 Jean-Marc Mifsud over 10 years ago in reply to Denis-24

TI__Mastermind 22375 points

Denis,

I've prepared a basic demo code that you can use with our bootloader.

This code is the Halcogen Blinky. It is located in the TMS570LS3137_Blinky_Bootloader (in the attache zip file)
You will find 2 configurations for this test:
1] Debug. It is used to debug this code without the bootloader.
2] Release. This is the version that you will have to download using the bootloader.

What is different between these 2 configurations is the linker command file.
In the Debug version, the sys_link_debug.cmd is used. In this configuration, VECTORS are mapped to 0x0000_0000 and FLASH0 is mapped to 0x0000_0020
In the Release version, the sys_link_release.cmd is used. In this configuration, VECTORS are mapped to 0x0002_0000 and FLASH0 is mapped to 0x0002_0020

0x0002_0000 is the reset vector for your application and this address is expected by the bootloader.

The bootloader project is located in TMS570LS3137/boot_uart

Both project are already compiled so you should be able to download the bootloader and run it as it is.

A serial terminal has to be connected using the USB port of the HDK board.
The default configuration (in actual build) are: 115200, 8bits, no parity, 1 stop
If you want or have to change the baudrate, is is defined in bl_config.h

Please have a try and let me know.

4863.SafetyMCU_Bootloader.zip

I will be out for the rest of the week, but will check the forum from time to time.

0 Jean-Marc Mifsud over 10 years ago in reply to Jean-Marc Mifsud

TI__Mastermind 22375 points

Denis,

I can also have a look to your application and see what is the root cause for the nERROR pin to be active.
Can you share this project?

0 Denis-24 over 10 years ago in reply to Jean-Marc Mifsud

Prodigy 90 points

Jean-Marc,

Thanks a lot for your basic Demo Code. I have compared your Demo Code with my Application Code. There are no fundamental changes between them. In your sys_intvecs.asm you've got a resetEntry, which I didn't had. I added that piece of code, but the red LED is still turned on after an application jump.

Jean-Marc Mifsud said:

Denis,

I can also have a look to your application and see what is the root cause for the nERROR pin to be active.
Can you share this project?

That would be great! As opposed to my previous post the Application resides now at 0x00180000 (Bank 1).

0 Jean-Marc Mifsud over 10 years ago in reply to Denis-24

TI__Mastermind 22375 points

Denis,

I was able to use your project.

The default configuration for the bootloader is to find the Application code at 0x0002_0000.

In your case, your application is linked to 0x0018_0000.

In order to debug your application, I've remapped your code to 0x0002_0000 and was able to download this application using the default configuration for the bootloader.
After download, your code is running correctly and I can see the 4 leds on. The code is than in a loop, waiting for some command.

So far so good.

I than recompiled my bootloader after changing in bl_config.h the APP_START_ADDRESS from 0x0002_0000 to 0x0018_0000 to match your application.
I also re-linked your application code to your default 0x0018_0000.

When I run the bootloader and try to download your application code (Option 1) the bootloader seems to get stuck somewhere.
I've forwarded this problem to the engineer in charge of this bootloader for help.

So in conclusion, I'm not seeing your problem.

Can you confirm that in your case you have modified the bl_config.h to specify the new application start address?

I also did the following test.

Using the default bootloader, (APP_START_ADDRESS = 0x0002_0000) I did a download of your application with a start address of 0x0018_0000.

The download is going through correctly, but the application code does not start.

I will suggest for now, to use the default start address in the bootloader and of course for your application. (0x0002_0000) until we figure out why the bootloader fails with 0x0020_0000 as application start address.

Also, in your project property I did not found the post process step to generate the .bin file expected by the bootloader.

"${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd.exe" "${CG_TOOL_ROOT}/bin/armhex.exe" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"

Please have a try and let me know your result.

0 QJ Wang over 10 years ago in reply to Jean-Marc Mifsud

TI__Guru**** 198546 points

Hi Jean-Marc,

There is a minor bug in bl_flash.c file of the bootloader. If the application is assigned to the 1st bank, it works fine. If the application is assigned to 1st sector of 2nd bank, the flash erase operation will be stuck up since the 1st sector is not enabled in the function. Please change 0xFFFE to 0xFFFF to fix the problem:

status= Fapi_enableMainBankSectors(0xFFFF); /* used for API 2.01*/

Regards,

0 Denis-24 over 10 years ago in reply to Jean-Marc Mifsud

Prodigy 90 points

Jean-Marc,

I've my own custom bootloader and I'm not using the default bootloader. It seems, that the application is running correct with the default bootloader. Therefore the bug must be reside in my bootloader. My bootloader is downloading an Intel-HEX File through SCI on Flash Bank 1 (0x00180000). The Intel-HEX File is created by CCS with: "${CG_TOOL_HEX}" -i "${BuildArtifactFileName}" -o "${BuildArtifactFileBaseName}.hex" -order MS -romwidth 16. The download is working very fine. But I'm not able to start the application. To avoid issues during the download I'm flashing the bootloader and the application with CCS. After that I'm starting the bootloader and trying to switch to the application. If the application start works I will try starting the application after downloading the Intel-HEX File.

1. Edit: If I download the Intel-HEX File and start the application the bootloader hangs in sys_intvecs.asm: undefEntry.

I've attached my bootloader. Maybe you can have a look? You can find the main-function in XBD_BL.c. For starting the application just execute XBD_switchToApplication(). You can also replace XBD_serveCommunication() (in main-function) with XBD_switchToApplication().

2. Edit: I have found out, that the Intel-HEX File, which I used before was wrong created. Because of the 16 Bit romwidth the first 16 Bits was cut off.

A content like

0xEA0012B5
0xEAFFFFFE
0xEAFFFFFE
0xEAFFFFFE
0xEA001D55

was made to

0x12B5FFFE
0xFFFEFFFE
0x1D55...

I changed the romwidth to 32 Bit. After downloading the Intel-HEX File to Flash the behaviour is like I'm downloading the application with CCS. The red LED is turned on.

3. Edit: I found the issue. All self tests were enabled in HALCoGen. I disabled all self tests under SAFETY INIT tab and the jump from bootloader to application works. Why is that a problem with enabled self tests?

0 Jean-Marc Mifsud over 10 years ago in reply to Denis-24

TI__Mastermind 22375 points

Denis,

I was about to reply with the same founding.

You are using Halcogen to generate the startup code for both bootloader and application.

In both cases, the PBIST selftest are enable.
When it is run first in the bootloader, everything is ok. But when it is run a second time in your application (without a reset in between) the RAM is initialized and a pop from the stack returns 0 as pc address and your code fails.

From a safety stand point it is not necessary to perform all this test in your bootloader.
The TI proposed booloader does not run any memory/CPU test. It is up to your application to take care of that.

Anyway, I will continue the debug, and want to understand why the second time PBIST Selftest is creating this issue.

Also, could you confirm which version of Halcogen you are using. According to the config file, it is 3.02.00 that is a really old version.
The actual up to date version is 04.02.00

I've tried to regenerate the bootloader with 04.02.00 but I'm facing some compiler error on SCI driver.
Description   Resource   Path   Location   Type
#137 struct "sciBase" has no field "BAUD"   tests.c   /Test_TMS570/xbd_hal   line 26   C/C++ Problem
Description   Resource   Path   Location   Type
#137 struct "sciBase" has no field "LENGTH"   tests.c   /Test_TMS570/xbd_hal   line 27   C/C++ Problem

I don't have 03.02.00 anymore to check.

I will keep you informed of my debug. I will be out for the rest of the week and will be back next week (not to say next year)

0 Jean-Marc Mifsud over 10 years ago in reply to Jean-Marc Mifsud

TI__Mastermind 22375 points

Denis,

I was able to perform more debug on your bootloader.

I found a mistake in the memoryInit() function. This problem is fixed in later version of Halcogen.

void memoryInit(uint32 ram)
{
/* USER CODE BEGIN (6) */
/* USER CODE END */

    /* Enable Memory Hardware Initialization */
    systemREG1->MINITGCR = 0xAU;

    /* Enable Memory Hardware Initialization for selected RAM's */
    systemREG1->MSINENA = ram;

    /* Wait until Memory Hardware Initialization complete */
    /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
    while((systemREG1->MSTCGSTAT & 0x00000100U) != 0x00000100U)
    {
    }/* Wait */

    /* Disable Memory Hardware Initialization */
    systemREG1->MINITGCR = 0x5U;

/* USER CODE BEGIN (7) */
/* USER CODE END */
}

In your old version of Halcogen, it is systemREG1->MINITGCR = 0xAU; leaving the Memory Hardware Controller enable.

But there is something else. The bootloader, because of all the Safety Test is enabling RAM ECC. So when you enter your application code, RAM ECC is already enable. Now again your application code is also testing the RAM using PBIST. As far as I know, this is not valid, and the ECC controller will detect multiple bit error, this will fire the ESM module and the error pin.

So in summary:

1] Use the latest release of Halcogen to avoid problems that are already fixed.
2] Remove from the bootloader all CPU, Memories test.
3] Run all these tests part of your application code.

0 Jean-Marc Mifsud over 10 years ago in reply to Jean-Marc Mifsud

TI__Mastermind 22375 points

Denis,

As far as I remember, older versions of Halcogen had a problem with the test of ECC.
Basically, to test ECC, single bit error and double bit error are introduced on purpose in RAM to check the detection.
The problem was that these errors were not removed from RAM, so later on, in the application code, if these locations are accessed, the ECC logic was detecting double bit error.
Again this is fixed in actual release of Halcogen.

0 Denis-24 over 10 years ago in reply to Jean-Marc Mifsud

Prodigy 90 points

Hi Jean-Marc,

Thanks a lot for your help! My bootloader is working now!

Jean-Marc Mifsud said:

Also, could you confirm which version of Halcogen you are using. According to the config file, it is 3.02.00 that is a really old version.

That's right. That was the version on the CD in the Hercules Development Kit. :-)

Jean-Marc Mifsud said:

The actual up to date version is 04.02.00

I installed already the newest version.

Jean-Marc Mifsud said:

I've tried to regenerate the bootloader with 04.02.00 but I'm facing some compiler error on SCI driver.

Thats not the SCI driver, thats a testing routine, which confirms if the SCI was set up correctly. In the new HALCoGen version there are two struct members renamed:

scilinREG->BAUD ==> scilinREG->BRS
scilinREG->LENGTH ==> scilinREG->FORMAT

Thats the cause of your/my compilation error.

Anyway it is working now and I know the cause. Thanks a lot!

Regards

Denis

Arm-based microcontrollers

Arm-based microcontrollers forum

Jump from Bootloader to Application