MCU does not start at startup address written in BMHDx

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
Hello all,

I am using TC332LP and flashed BMHD0 using WinIdea UCB Plugin. I confirmed the written data by checking memory window of the debugger at address 0xAF40_0000. In BMHD, my start address is A000_0000 and my startup code is here.
If I download application code, my program counter (PC) is in correct address only once and winidea shows it correctly and works fine without an issue.
If I reset or power off-on, then my PC starts at address 0xA00A_0020 and code does not work as intended. Do you give me some clues why my PC becomes 0xA00A_0020 when I reset the MCU.

I've attached the memory window.

5119.attach
0 Likes
15 Replies
VincentWan
Employee
Employee
50 replies posted 5 sign-ins First like received
Hi

u can refer appnote AP32381_AURIX_2ndGeneration_Startup_and_Initialisation in myICP for details.

it maybe a watchdog issue since you mentioned you can run your code with debugger connected? (ie, did you disable the WDT in your code)
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
Hi,

thank you, I will check the document you mentioned.

It works in first download, then if I reset the mcu, it does not work even with debugger connected.

WDT is disabled by debugger. there is an option in winidea that we can disable watchdog at initialization and this option is enabled.


EDIT: It does not work even in first download. It was our fault, we thought it is working but in reality it works because of debugger option "go to entry point". If we disable this option, it does not start from address inside of BMHD. To sum up it does not work in any condition.
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
I found this register SCU_STMEM1 and the register value is 0x010045C1 (HaltAfterReset).

BMI_VALID bit is invalid and I dont know why this bit is invalid.

As you can see in the attached screenshot of my message, BMHDID is 0xB359 and it is correct, Locksteps are disabled, HWCFG is 111b which is start from internal flash and PINDIS is 0 which is mode selected by HWCFG pins is enabled.

Which register should I check for why BMI_VALID bit is invalid?
0 Likes
ScottW
Employee
Employee
10 sign-ins First solution authored First like received
It looks like you have valid CRCs written. What do SCU_STMEM3 and SCU_STMEM4 look like?
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
We didn't calculate them manually, CRCs are calculated by WinIdea UCB Plugin. Also we used online CRC calculator to check written CRCs and values are same as in the memory.

Do invalid CRCs brick the MCU?

https://crccalc.com/?crc=B359000EA0000000&method=crc32&datatype=hex&outtype=hex
0 Likes
ScottW
Employee
Employee
10 sign-ins First solution authored First like received
No, I didn't hit "recalculate" when I put my CRCs together. Yours are correct.

An invalid BMI may keep the device from executing the user code, but will allow reflashing with a proper BMI.
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
Scott Winder wrote:
An invalid BMI will keep the device from executing the user code, but will allow reflashing with a proper BMI.

Oh that's good to hear. Thank you for clarification.

Btw, SCU_STMEM2 register value is 0xA00A0021 which is BOOT_ADDR written by SSW.
SCU_STMEM3 is 0x0000_0007
SCU_STMEM4 is 0x0000_0001
0 Likes
ScottW
Employee
Employee
10 sign-ins First solution authored First like received
How about the value of DMU_HF_CONFIRM0?
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
Dmu_hf_confirm0:

5122.attach

Edit:
added SCU_STSTAT:
5123.attach
0 Likes
ScottW
Employee
Employee
10 sign-ins First solution authored First like received
Can you try updating your BMI to 0x000F? It doesn't look like your HWCFG pins are set to start from flash, but using that BMI setting will override them.
0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored
CONFIRMATION code is correct in the BMHD?
What contains 0xAF4000F0--0xAF4000FF?
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
Scott Winder wrote:
Can you try updating your BMI to 0x000F? It doesn't look like your HWCFG pins are set to start from flash, but using that BMI setting will override them.


This solved the issue mostly. Our HWCFG pins are configured as output, I don't know how this affect startup.
If we disconnect debugger, it stops working. We will try to disable wdg at startup maybe this will solve completely.
0 Likes
hmkum
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked
MoD wrote:
CONFIRMATION code is correct in the BMHD?
What contains 0xAF4000F0--0xAF4000FF?


Confirmation code is 0x43211234 (in memory window - 0x34 12 21 43)

It looks correct to me.
0 Likes
PeterNemeth
Level 1
Level 1
First reply posted Welcome!

Hello,

we are facing in our project a very similar problem, and wanted to ask whether this issue had a solution?

0 Likes
Photon
Level 1
Level 1
First reply posted 10 sign-ins 5 sign-ins

Hello,

During debugging with TC39 controller, we observed an issue similar to yours. Flashed software starts the ECU with the intended PC address using Trace32, but reboots or power cycles lead to an unpredictable startup address within the BMIField, causing program execution failures.

could any one support here ?

0 Likes