• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 748 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Rm46 bootloader written program does not run from start address 0x20000

Johannes Schuster
Prodigy 110 points
Other Parts Discussed in Thread: HALCOGEN

Hello,

to test my bootloader on a RM46L852PGE board I use a little test program that simply blinks an LED on the board. This program runs fine if written to address 0x0 with the debugger.

However if I use the bootloader (based on TI provided SafetyMCU_Bootloader sample) to write the program to address 0x20000 it does not run correctly.

When the System is powered up it starts the bootloader and after a few seconds when the bootloader does not receive any command from CAN Interface it jumps to address 0x20000 to start the application software (the blink program). The blink program seems to run, but it runs very slow. Instead of blinking every second, it blinks only about every 16 seconds. Any clues what could be the reason for that?

I must say that on the board that comes with the TI drv8301-rm46 development kit with the RM46L852ZWT MCU everything works fine. So it happens only on the target hardware with the RM46L852PGE device.

Thanks for your help.

Johannes

  • 0
    TI__Genius 11645 points
    Hi Johannes,

    Both the packages that you have mentioned have same size of Flash and other dependencies identical that I can think off.

    Since you have said you are using two different boards and another interesting observation of the LED blinking 16 times slower, here are my hunches...

    Can you pls check your oscillator on the board with RM46L852PGE device once again, if there is an issue with OSCIN and Clock Detection circuit comes in and gets the device hooked on to HFLPO which is 10MHz and I see the default PLL config to output 160 MHz for a 16MHz oscin under normal circumstances.

    160MHz(Expected Frequency)/10MHz(HFLPO) = 16, may be the reason why its running 16 times slower. You can also check the ESM register to see if there is an OSCFAIL. Please let us know
  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    TI__Genius 11645 points
    Hi Johannes,

    Can you pls close this thread if your issue is solved. Thanks.
  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    Prodigy 110 points
    Hello Karthik,

    unfortunatly it is not resolved at all. On some boards we experience a PLL slip, We assume this is due to the switch of the HCLK frequency when the bootloader jumps to the application start address and the application reconfigures the MCU.

    Another reason might be that the bootloader does not fully initialize the MCU and then the MCU is in a random state when the application gets started. I must say the the source code from the bootloader sample provided by TI is terrible, buggy and just ridicoulous regarding uninitialized variables, error handling and style. Have a look at bl_flash.c and see for yourself if you like.

    So currently I try to build the bootloader gain from scratch using Halcogen for MCU initialization. But so far the Flash API behaves very strange. I let you know when I have new results.

    Regards
    Johannes
  • 0 in reply to Johannes Schuster
    TI__Genius 11645 points

    Hi Johannes,

    I'm forwarding your post to our Boot loader experts to assist you better.

  • 0 in reply to KARTHIKEYAN RAJAMANICKAM
    TI__Guru**** 186206 points
    The bootloader on TI website is just a sample for RM46 BGA package. If you want to run it on QFP package, you need to change the flash settings etc.
    Regards,QJ
  • 0 in reply to QJ Wang
    Prodigy 110 points
    Hi all,

    the reason for the behavior is in fact the PLL slip which I mentioned in my previous post. The device then goes into error state and runs with reduced takt. I have no idea why this happens on some devices and on others not. However if I turn off PLL slip detection by setting the appropriate bits in PLLCTL1 the application works fine on all devices.

    Like so in system.c:
    systemREG1->PLLCTL1 = 0x00000000U
    | 0x40000000U // Turn off PLL slip
    | ...

    So I consider this problem (at least the symptoms) fixed.

    Regards
    Johannes
  • 0 in reply to Johannes Schuster
    TI__Genius 11645 points
    Johannes,

    Can we close this thread ?
  • 0 in reply to Johannes Schuster
    TI__Mastermind 49120 points
    Johannes,

    I presume that you have disabled the MCU's response to a PLL slip being detected. This may not be what you want if you are working on a safety application.

    The PLL slip must be occurring because the application and the bootloader are both configuring the PLL control registers with different values. If both these components of your code do indeed need to configure the PLL, the recommended procedure would be to first disable the PLL via the Clock Source Disable (CSDIS/CSDISSET) Register, then configure the PLL control registers, and then to re-enable the PLL (again via the CSDIS/CSDISCLR register. See section 10.5.2 on page 385 of SPNU514a for more details.

    Regards,
    Sunil