MPC5604P BAM UART Mode (strange behavior)

[simbasoft]

Hello,

We made a custom boot loader software to load it via the BAM in UART Mode. We are testing it on the TRK-MPC650P Development Kit. Generally it works, but not always.

We are experiencing a strange issue with the BAM of the MPC560P MCU:

1. If we load the boot loader software through the Code Warrior IDE, into the RAM of the MCU, then it allays works. We are able to communicate with it via LIN_0 Module and execute the commands. No issues, all the commands execute 100% as expected.
2. it does work - but not always, if we load the boot loader software through the BAM, using a custom Windows application:
   • the BAM always loads the boot loader software into the RAM of the MCU,
   • after the BAM loads the boot loader into the RAM, sometimes but not always, executes it. When the BAM executes the boot loader it works 100% as expected
3. most of the time, we could not explain why, after BAM loads the boot loader into the RAM, instead of executing it, it re-executes itself again from the beginning - as if there was a power power-cycle reset. It will reconnect to the PC application and reload the boot loader, then back to executing itself again.
4. it always works, if before communicating with the BAM we use the Code Warrior IDE and connect to the MCU at least once (just connect to the MCU and disconnect doing absolutely nothing), then do a short power-cycle (turn off for a couple of seconds - but not for too long), then load the boot loader software via the BAM. It executes 100% as expected.
5. same as #4, but after connecting the debugger we keep the power turned off for too long, then it will not work. This can only happen, if we think that some capacitor(s) is getting discharged when we keep the power off for a longer period of time. But I don't get the relationship with the debugger and BAM!!

Anybody can help?

Thank you in advance

[lukaszadrapa]

Hi,

here is what comes into my mind:

1. The base address of downloaded code must be 0x4000_0100 or higher. It is not possible to use area 0x4000_0000 - 0x4000_00FF.

2. If it works when debugger was connected, it could be caused by watchdog or ECC errors in RAM. Have you disabled watchdog in your bootloader? The RAM memory is initialized when the BAM copies user code to RAM memory. If you want to use RAM memory outside this area (outside the image which is copied to RAM) then it must be initialized explicitly by SW.

3. If it helps, here you can find description how to create RAM image which is downloaded by BAM:

Re: Boot Assist Module (BAM) with FlexCAN MPC5604P

Lukas

[simbasoft]

Hi Lukas,

Thank you for the quick response.

1. The base address is at 0x4000_0100;
2. The watchdog is disabled by the boot-loader SW;
3. At power-on rest, the ECC is supposed to be by default disabled (we are not enabling it);

I think, not initializing the memory outside the downloaded image is the issue - e.g. the stack, and might be related to #3 above. We are updating the boot-loader SW to initialize all RAM that is outside the downloaded image.

I will update again once we have a final confirmation .

Thanks again,

Zouhrab

[lukaszadrapa · Accepted solution]

Hi,

ECC is enabled all the time. It can't be disabled. Single bit errors are automatically corrected and double bit errors are always reported - exception is triggered. All you can do is to enable/disable additional reporting in ECSM module. But you can't disable triggering of exception in case of double bit error. If you access the SRAM outside the downloaded image then I'm sure this is the root cause.

Lukas

[simbasoft]

Thank you, Lukas!

We have updated the SW to initialize the RAM outside the downloaded image. It works!

Zouhrab