AURIX™ Forum Discussions

[hmkum]

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.

[VincentWan]

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)

[hmkum]

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.

[hmkum]

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?

[ScottW]

It looks like you have valid CRCs written. What do SCU_STMEM3 and SCU_STMEM4 look like?

[hmkum]

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

[ScottW]

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.

[hmkum]

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

[ScottW]

How about the value of DMU_HF_CONFIRM0?

[hmkum]

Dmu_hf_confirm0:



Edit:
added SCU_STSTAT:

[ScottW]

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.

[MoD]

CONFIRMATION code is correct in the BMHD?
What contains 0xAF4000F0--0xAF4000FF?

[hmkum]

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.

[hmkum]

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.