m4 reload from linux fails

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

m4 reload from linux fails

2,671 Views
evanthompson
Contributor II

On an i.mx7d, I can't get reloading the m4 from linux to work. I'm trying the utility from this blog post:

New i.MX6SX & i.MX7D AMP debugging tool: imx-m4fwloader 

 

The problem is that swapping between 2 different m4 binaries does not work (reloading the same binary repeatedly does work). I'm using a stock sabre board and demo examples from the nxp bsp, so hopefully this will be easy to reproduce.

 

Setup to reproduce the issue:

i.mx7d sabre board with imx7d-sdb-m4 device tree

Copy these files to the sabre board:

m4fwloader binary from the above blog post

hello_world_ocram.bin example from nxp's FreeRTOS BSP

hello_world_2.bin, a second m4 binary that has one extra printf() call. Replace the hello_world main.c with the attached and rebuild hello_world_ocram. Rename the binary"hello_world_2.bin"

 

Boot linux and run these commands:

./m4fwloader /path/to/hello_world_2.bin 0x910000

./m4fwloader /path/to/hello_world_ocram.bin 0x910000

 

After the first command, the m4 starts, and the messages print to the terminal.

After the second command, the m4 will not start.

Original Attachment has been moved to: main.c.zip

Labels (2)
7 Replies

1,804 Views
evanthompson
Contributor II

For anyone who comes across this in the future - the problem was in register SRC_M4RCR (0x3039_000C), which is used to stop and start the m4. The m4fwloader program is leaving the ENABLE_M4 bit set while the new firmware is written, but it needs to be disabled - otherwise the currently-running application may attempt to write to the same memory area as the new firmware.

1,804 Views
dogisfat
Contributor IV

When ENABLE_M4 is set to "0" it seems like some of the memory doesn't get written. I am using the TCM for reference and I am guessing the ENABLE_M4 bit may disable the clock to that memory. Instead I am using the SW_M4C_NON_SCLR_RST (bit 0) to hold the M4 in reset while I do the programming. The reference manual and AN5317 BADLY need to be updated to reflect a proper programming cycle when the M4 is already running. In my case the M4 uses DDR (RPMSG and general memory). Occasionally without the M4 being held in reset it would crash BOTH the A7 cores and the M4 rendering the system completely dead.

0 Kudos

1,804 Views
dry
Senior Contributor I

EDIT

I've re-checked it now, and the original imx-m4fwloader app as referred to,  the author was from NXP, also didn't fully follow ap note as recommended.

No full platform reset was issued, only core reset & hold (bit 0).

I kinda feel full platform reset is what one would want 

0 Kudos

1,804 Views
art
NXP Employee
NXP Employee

Try to do 'm4fwloader stop' first, then reload a binary then do 'm4fwloader start'.


Have a great day,
Artur

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,804 Views
evanthompson
Contributor II

Hi Artur,

Any further ideas on this issue?

Thanks,

Evan

0 Kudos

1,804 Views
evanthompson
Contributor II

Hi Artur,

Thanks for the response.

Running 'm4fwloader stop' and 'm4fwloader start' does not fix the problem. This is expected - if you look at the m4fwloader code, you will see that reloading a binary was already doing a stop and start.

Thanks,

Evan

0 Kudos

1,804 Views
art
NXP Employee
NXP Employee

mareknovak‌ , can you please help us here with your m4fwloader tool?

Thanks in advance.

Artur

0 Kudos