Few questions about HSE installation via MU interface

BianHaopeng

Hi,NXP

I'm trying to install HSE via MU interface in my S32K344 development board.

After reading lots of docs and files, i still have some questions.

1. I want to put pink-image in sram. I tried to use ld file to put image in sram directly,but it seems to fail. (Use ld file to put image in flash is OK)
HSE_FLASH : ORIGIN = 0x00502000, LENGTH = 0x00030000

HSE_SRAM : ORIGIN = 0x20410000, LENGTH = 0x00030000

As an alternative solution, now I disable MPU, and use memcpy to copy image to ram from flash, that works.

2. I use "Power_Ip_PerformReset(&Power_Ip_HwIPsConfigPB);" to call a functional reset.

when "Power_Ip_PerformReset"is triggered, content in sram lost,and go to the first line of main function. This seems not fit with docs,

Is my usage correct? Is this the normal behavior of a functional reset?

3. How to write and read DCMRWP1 and MU Rx/tx register via app. I tried to use jlink in debug, but failed to read and write.

thank you very much.

lukaszadrapa

The RAM memory must be initialized:

This initialization is required after POR reset and after destructive reset when the RAM content is invalid. RAM content is retained across functional resets, so RAM initialization is not necessary in this case.

The "????????" in the debugger means that the debugger is not able to read the data. In case of RAM, it's due to ECC errors when the RAM has not been initialized.

To answer your questions:

1. Functional reset will make "App core" back to first line of main.c, but installation need 2 functional reset. Can I keep PC pointer not be reset?

- Functional reset will force the program counter to entry point, not to first line of main.c. If a debugger stops at first line in main function, it's caused by breakpoint. It's not possible to keep PC across resets. As I mentioned above, the RAM content is kept during functional resets. The RAM initialization can be conditional - your startup code doesn't need to initialize the RAM after functional reset.

2. I don't know how to write and read these registers via app, can you teach me?

- Those are normal memory-mapped registers. You can read/write the registers as any other peripheral registers. The MU installation method described in HSE FW RM even contains addresses of those registers.

Regards,
Lukas

View solution in original post

lukaszadrapa

Hi @BianHaopeng

First of all, is there any specific reason to use installation via MU interface? This is usually used rather for recovery purposes. Installation via IVT is more common method.

The pink image can be left in the flash memory. It’s not necessary to move it to RAM. After reset, the RAM is initialized by startup code and also variables are cleared/initialized. This is probably the reason why the image is not available in the RAM anymore.

Also debuggers have usually problems to catch a reset event and the behavior can be sometimes unpredictable after reset. It’s better to test such operations without a debugger.

I had no problem to install the firmware via MU interface when using Trace32 debugger from Lauterbach. The timeouts are long enough, there should be no problem to perform the sequence manually in a debugger.

How do you write to DCMRWP1 register? Only 24:31 bits should be written. I simply read out content of the register, mask the bits 24:31 accordingly and then I wrote that value back. This worked on my side.

Regards,

Lukas

BianHaopeng

Thank you very much for your reply.

My company manufactures programmers. One of our customers choose to use MU installation, and put image in SRAM. So I'm study on it, trying to find the implementation plan on the self-developed programmer.

The reason why content in sram is erased is found:

In .ld file, there's one configuration "__RAM_INIT = 0;" This lead to sram init every reset.

I don't have trace32, so I use Jlink. I tried to modify directly via debugger, but failed.

WARNING: Failed to read memory @ address 0x402AC2C0

WARNING: Failed to read memory @ address 0x402AC66F

So I'm looking for new method, my idea is control MU via app.

Currently, my main confusion lies in the following points:

1. Functional reset will make "App core" back to first line of main.c, but installation need 2 functional reset. Can I keep PC pointer not be reset?

2. I don't know how to write and read these registers via app, can you teach me?

I am new to this installation method and this IDE, so my understanding of it may have some inaccuracies. I hope you can be understanding and correct me if there are any mistakes.

Is control MU installation via app feasible? or some other methods is better?

lukaszadrapa

The RAM memory must be initialized:

This initialization is required after POR reset and after destructive reset when the RAM content is invalid. RAM content is retained across functional resets, so RAM initialization is not necessary in this case.

The "????????" in the debugger means that the debugger is not able to read the data. In case of RAM, it's due to ECC errors when the RAM has not been initialized.

To answer your questions:

1. Functional reset will make "App core" back to first line of main.c, but installation need 2 functional reset. Can I keep PC pointer not be reset?

- Functional reset will force the program counter to entry point, not to first line of main.c. If a debugger stops at first line in main function, it's caused by breakpoint. It's not possible to keep PC across resets. As I mentioned above, the RAM content is kept during functional resets. The RAM initialization can be conditional - your startup code doesn't need to initialize the RAM after functional reset.

2. I don't know how to write and read these registers via app, can you teach me?

- Those are normal memory-mapped registers. You can read/write the registers as any other peripheral registers. The MU installation method described in HSE FW RM even contains addresses of those registers.

Regards,
Lukas