S32K144 Bootloader --> JumpToApplication Problem

Discussion created by Paul Klarhöfer on Feb 8, 2019
Latest reply on Apr 21, 2019 by qyq echo_

Like • Show 2 Likes2
Comment • 11

Hi,

I use the UART Bootloader from the AN12218 example.

I'm using in my application a FreeRTOS. When I do implement only a blinking LED Task, it is working, also with the right frequency.

But it seems like, that no peripheral (UART, SPI, I2C, CAN) is acutally working. For example, when I try to send CAN messages out, when the application is loaded from the bootloader, my CAN device detects only errors.

So for me it seems like, I'm missing something here. Is there something else, that needs to be reset, when switching from the bootloader to the application? Or maybe is my linker file wrong?

The main problem is also, that I do not know how to debug this problem, becuase it only appears, when the application is loaded from the bootloader, when I only download the application (with start address 0x0 in linker file), than the program works perfectly fine.

I hope somebody has an idea.

JumpToApplication function:

Bootloader Linker file:

Application linker file:

Outcomes

11 Replies

Diana Batrlova Feb 11, 2019 1:53 AM
Hi Paul,

The Linker files seem to be correct.
Could you please try to create a simple interrupt application as your user application and loaded it by the bootloader?
(for a check that issue is not because of interrupts).

Also, you can try to check the registers in S32DS using Attach feature.
This allows you to search the registry even after a reset.

I hope it helps you.
Best Regards,
Diana
Like • Show 0 Likes0
Actions
- Paul Klarhöfer @ Diana Batrlova on Feb 11, 2019 5:10 AM
  Hi Diana,
  
  I tried the hello_interrupts example and it is working correctly.
  I also tried the FlexCAN example and it does also work.
  
  Next thing to figure out: Why does it not work within my freertos, when loaded from the bootloader...
  Like • Show 0 Likes0
  Actions
  - Diana Batrlova @ Paul Klarhöfer on Feb 12, 2019 1:42 AM
    Hi Paul,
    
    Did you try to look at your register settings by Attach feature in S32DS after the jump?
    
    The interrupts can be disabled by this code: __asm("cpsid i");
    
    Best Regards,
    Diana
    Like • Show 0 Likes0
    Actions
stanish Feb 11, 2019 6:41 AM
Hi Paul,

This might be an issue with LSB bit...please check this thread:
https://community.nxp.com/thread/469549#comment-986866

I'd also suggest to disable interrupts before jumping to the application.

Stan
Like • Show 0 Likes0
Actions
- Paul Klarhöfer @ stanish on Feb 11, 2019 8:31 AM
  Thanks for the Feedback Stan.
  
  Unfortunately I don't understand what I need to change regarding to the LSB bit problem. For me it seems also, that this thread has been unresolved or I don't see the answer.
  
  Regarding the interrupts: How do I disable them all with one command?
  Like • Show 0 Likes0
  Actions
  - stanish @ Paul Klarhöfer on Feb 12, 2019 6:47 AM
    Hi Paul,
    
    Please ignore my suggestion regarding LSB bit ... I haven't test instruction that moves address to PC. I typically saw branching into application e.g. https://community.nxp.com/thread/451750#comment-908810
    Anyway, I'd strongly recommend you to get the MCU into state as close as possible to the after reset values.
    I'd focus on peripherals used by bootloader that generate interrupts -> de-initilaize these modules so they cannot invoke an interrupt when the global interrupts are enabled.
    Such pending interrupts could execute interrupt handlers that are not used by the application so the execution can ends up in the default interrupt handler or in a fault exception.
    
    Note:
    If you 'd like to debug both application and bootloader together please check this document:
    HOWTO: Debug multiple elf files in S32 Design Studio with GDB
    
    This will help you to debug the issue.
    
    Hope it helps.
    Stan
    Like • Show 0 Likes0
    Actions
    - Paul Klarhöfer @ stanish on Feb 21, 2019 8:12 AM
      Hi,
      
      I was able to debug it deeper. Now I think I found the problem:
      
      The bootloader did not write the complete application to the flash.
      The bootloader is unable to write data bytes to the flash memory if the adress is greater than 0x13F80.
      
      The FlashProgram function in fsl_flash_driver_c90tfs.c returns always FTFx_ERR_ACCERR for flash adresses greater than 0x13F80... The only thing I found out so far, that the flash Config was made for the S32K148 since the AN12218 project was originally a s32k148 project.
      
      Is this the problem? How can I solve it?
      This is the current flash configuration:
      
      I also tried to change, so it will more suit the s32k144, but with no success (I reduced the pflashSize to
      0x00080000U)
      
      Does these values matter or is it something else?
      
      Is the memory above 0x13F80 somehow locked?
      
      Thanks for helping
      
      Paul
      
      Like • Show 0 Likes0
      Actions
Paul Klarhöfer Feb 24, 2019 6:17 PM
I figured my problem out and also from the AN12218 Bootloader UART example.

First of all: The demoCode of the AN12218 does not return any error code if erasing sectors or programming sectors have generated errors. The error codes are generated by the flash drivers, but are not being passed to mem_man.c file or the comm.c file. With that you don't know if a write operation was successfull

Second problem: In order to write data to the flash memory of the S32Kx family, the flash adress must be 64-bit aligned. That means that the least three bits (2:0) must be zero. Unfortunately the S32 Design studio produces srec files which are not 64-bit aligned. To make a srec file 64-bit aligned some external tool needs to be used. It is described here: Aligning S19 Records to 64-bit Boundaries | MCU on Eclipse

My feature request for NXP is: Make an option in S32 design studio to produce 64-bit aligned srec files. Now everytime I have to use that external tool to make it 64-bit aligned, which is kind of annoying and it was really hard to find out that this caused the problem in the first place.

Thanks for your help.
2 people found this helpful
Like • Show 1 Like1
Actions
- Diana Batrlova @ Paul Klarhöfer on Feb 26, 2019 7:36 AM
  Hi Paul,
  
  Thank you for your comments. It will be useful for other customers.
  Also, the Memory window in the S32DS can be useful to check the data in the memory.
  For example:
  
  Actually, the information about the 64-bit aligned address is placed under the "Table 36-40. Program Phrase Command FCCOB requirements" in the RM rev 9.
  "The Flash address Must be 64-bit aligned (Flash address [2:0] = 000)"
  
  The "My feature request for NXP" is rather for the IDE support. Probably Stanislav Sliva has more information.
  
  Best Regards,
  Diana
  Like • Show 0 Likes0
  Actions
- Milos Lovric @ Paul Klarhöfer on Mar 8, 2019 6:33 AM
  Hello Paul!
  
  Same problem here. Have you found a solution (other than external tool)?
  Like • Show 0 Likes0
  Actions
  - qyq echo_ @ Milos Lovric on Apr 21, 2019 11:29 PM
    Hi,
    Changing the values in parentheses after the ALIGN(in xxx.ld file) may be useful.
    Like • Show 0 Likes0
    Actions

S32K144 Bootloader --> JumpToApplication Problem

Outcomes

Related Content

Recommended Content