Writing Firmware directly in RAM

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

Writing Firmware directly in RAM

4,154 Views
arunmuthuganesh
Contributor I

Hi Everyone,

 

I am trying to run the firmware directly in RAM using sdphost application in i.MXRT1060 and I am not successful. 

By following the steps provided in "User Manual - MCUXpresso Secure Provisioning Tools" document, I have created the .axf file with the below configuration.,

 

pastedImage_1.png

 

 

pastedImage_2.png

 

pastedImage_3.png

 

I have used the "usb_device_dfu_lite" example provided in SDK. After generating the .axf file, I am using the Binary Utilities to generate the .bin file.

 

With Sdphost, .bin file can be directly written in RAM and start execution.

 I have tried the below commands and I am not successful.

 

sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x20000000 XYZ.bin

sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x2000000

 

By providing these commands, the execution does not start. What is the exact procedure to write the firmware directly in RAM and start its execution?

Regards,

Arun

Labels (1)
0 Kudos
Reply
12 Replies

3,368 Views
Lorac
Contributor III

It seems that the issue come from elftosb tool itself. You must use 'srec' format file instead of .axf. You may generate it by doing a right click button over the axf file (select Binary Utilities then Create S-Record ). Or add this line [arm-none-eabi-objcopy -v -O srec "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.s19"] in your post-build steps, to create the support format file. The tool forget some sector in the conversion.
BR

0 Kudos
Reply

3,854 Views
arunmuthuganesh
Contributor I

Thanks jeremyzhou‌ for sharing the steps to create bootable image.

I have already tried creating bootable Image using with MCUXpresso Provisioning Tool which contains the IVT. I used the .axf created using the above steps as input for the MCUXpresso Provisioning Tool.

pastedImage_2.png

I got the bin files.,

evkmimxrt1060_dev_dfu_lite_bm.bin

evkmimxrt1060_dev_dfu_lite_bm_nopadding.bin

I viewed the files in hex viewer and I could see the IVT present in these bin files.

IVT at 0x1000 in "evkmimxrt1060_dev_dfu_lite_bm.bin"

IVT at 0x0000 in "evkmimxrt1060_dev_dfu_lite_bm_nopadding.bin"

I tried the following Commands.,

For "evkmimxrt1060_dev_dfu_lite_bm.bin"

sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x20000000 evkmimxrt1060_dev_dfu_lite_bm.bin

sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x20001000

For "evkmimxrt1060_dev_dfu_lite_bm_nopadding.bin"

sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x20000000 evkmimxrt1060_dev_dfu_lite_bm_nopadding.bin

sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x20000000

For both the above cases, I am correctly pointing the IVT address during jump-address command. But unfortunately code execution does not start.

Am I missing something here? 

 

I have also attached the .axf and .bin files for your reference.

Thanks & Regards,

Arun

0 Kudos
Reply

3,854 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Arun Muthuganesh,

Thanks for your reply.
Please follow the below steps to make it.
Note: I've attached the imx_application_gen_win.bd and the evkmimxrt1060_dev_dfu_lite_bm.srec is the image file of your demo project, it also can be bin format.

1) elftosb -f imx -V -c imx_application_gen_win.bd -o evkmimxrt1060_dev_dfu_lite_bm.bin evkmimxrt1060_dev_dfu_lite_bm.srec

2) sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x0 evkmimxrt1060_dev_dfu_lite_bm.bin
3) sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x1000

Have a great day,
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

3,854 Views
arunmuthuganesh
Contributor I

Thanks jeremyzhou‌ for your prompt response and the steps to write the Firmware directly in RAM.

Unfortunately the code did not start execution. I have followed the below steps.,

I used the .bin and .srec files created in the folders "secure_provisioning\bootable_images" and "secure_provisioning\source_images" respectively by using MCUXpresso Provisioning Tool.

I carried out the below commands.,

1) elftosb -f imx -V -c imx_application_gen_win.bd -o evkmimxrt1060_dev_dfu_lite_bm.bin evkmimxrt1060_dev_dfu_lite_bm.srec

 Using the above command, I got the "evkmimxrt1060_dev_dfu_lite_bm.bin" file created using elftosb.

2) sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x0 evkmimxrt1060_dev_dfu_lite_bm.bin
3) sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x1000

On executing the commands 2 and 3, I got the following Error.

pastedImage_1.png

So, I tried with the below commands by changing the address.

1) sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x20000000 evkmimxrt1060_dev_dfu_lite_bm.bin
2) sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x20001000

On executing the above commands, the stats returned was success, but the device was not enumerated as DFU but falls back to Serial Downloader Mode. This indicates that the DFU program execution is not started.

pastedImage_3.png

I have also attached the .bin file created using elftosb  for your reference.

Can you please check the behaviour on your side using the attached files? 

Thanks & Regards,

Arun 

0 Kudos
Reply

3,853 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Arun Muthuganesh,

Thanks for your reply.
I've done similar testing as you did, and it works well on my site.
The complete steps are below.
1. Generate bin file

pastedImage_1.png
Note: the axf is the image file of my project whose begin address is 0x20002000.

pastedImage_3.png
2. Program the bin file to the MCU via sdphost

pastedImage_4.png
3 Test
 You can input any character in a terminal tool, the MCU will print the character back, and it also prints this string: "Executing in RAM".

I've attached my project and imx-dtcm-unsigned.bd, please give a try.

Have a great day,
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

3,853 Views
arunmuthuganesh
Contributor I

Thanks jeremyzhou‌ for your detailed steps. By following your steps I am able to write the Firmware in RAM and start its execution but there arises a new problem.

I have tried your project and "evkmimxrt1060_iled_blinky" example. In both the case, I am able to successfully write and execute the Firmware in RAM.

But now, I got a new problem. When following the same steps for "evkmimxrt1060_dev_hid_generic_lite_bm" and "evkmimxrt1060_dev_hid_generic_lite_bm", the firmware got successfully written in RAM and execution is started but I am getting "Unknown USB device" Error in windows.

The USB examples failed to enumerate if directly written in RAM and execution is started. Also, If I try to write the same Firmware in QSPI, the bootloader automatically loads the firmware in RAM and the device gets correctly enumerated. But my requirement is to write the firmware directly in RAM.

Do I need to follow any other steps to write the USB examples correctly in RAM and start its execution using sdphost ?

Thanks & Regards,

Arun Muthuganesh

0 Kudos
Reply

3,853 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Arun Muthuganesh,

Thanks for your reply.
1) Do I need to follow any other steps to write the USB examples correctly in RAM and start its execution using sdphost?
-- To figure it out, I'd like to suggest you use USB analyzer to investigate what issue encounter during the USB enumeration process, it may give us some clues.

Have a great day,
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

3,853 Views
arunmuthuganesh
Contributor I

Thanks jeremyzhou for your reply.

 

Using USB analyser to investigate the issue is a good suggestion. But I think the problem may be due to issue in writing the firmware in RAM rather than Issue in USB firmware or Protocol.

 

I have Flashed the same USB firmware in 2 different ways.

 

Method 1 : Wrote the Firmware in SPI Flash. Bootloader is able to transfer the data to RAM and device is successfully enumerated as USB device.

 

Method 2 : Wrote the firmware directly in RAM and start its execution. Here the device fails to enumerate.

 

As the firmware works fine without any issues in Method 1, I assume that there is no problem with the Firmware or the USB protocol. (The firmware used is the DFU example given along with the SDK)

 

Am I missing something while writing the USB firmware in RAM or is there any other procedure for writing the firmware in RAM?

Thanks,

Arun 

0 Kudos
Reply

3,853 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Arun Muthuganesh,

Am I missing something while writing the USB firmware in RAM or is there any other procedure for writing the firmware in RAM?
-- I‘ve replicated this USB enumeration fail phenomenon on my site, and I guess it's related to RAM size limitation, the RAM seems to be incapable of running a bit big demo code.
So I'd highly recommend you select Method 1 to make it.

Have a great day,
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

3,853 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Arun Muthuganesh,

Thanks for your reply.
It seems a bit weird, and whether you can introduce the testing steps of your two methods, as I'd like to replicate the phenomenon on my site, it may help me to figure this phenomenon out.
Looking forward to your reply.

Have a great day,
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply

3,853 Views
arunmuthuganesh
Contributor I

Hi jeremyzhou‌, Thanks for your Reply.

I have used the DFU example that comes along with 2.7.0 SDK without any Modifications. I have also attached the source for your reference.

Method 1 : Writing Firmware in Flash

In this method, the Firmware will be written in SPI Flash. After reset, the bootloader transfers the firmware from SPI Flash to RAM and the device gets successfully enumerated as DFU.

Configuration Used :

pastedImage_2.png

pastedImage_3.png

The generated .axf file will be converted to .bin file with the help of MCU Provisioning Tool and will be flashed to SPI with the help of the same MCU Provisioning Tool.

pastedImage_2.png

After Reset the device will be successfully enumerated as DFU.

Method 2 : Writing Firmware directly in RAM

I have followed the same procedure as mentioned by you in the previous post. 

Configuration Used :

pastedImage_2.png

pastedImage_1.png

After the .axf file is created, it is converted into .bin file using the command.,

>elftosb.exe -f imx -V -c imx-dtcm-unsigned.bd -o DFU_Example.bin evkmimxrt1060_dev_dfu_lite_bm.axf

>sdphost.exe -u 0x1fc9,0x0130 -- write-file 0x20000000 DFU_Example.bin
>sdphost.exe -u 0x1fc9,0x0130 -- jump-address 0x20000400
After giving these commands, the device fails to enumerate.
These were the steps we followed.
Please let me know if I am doing anything incorrect.
Regards,
Arun
0 Kudos
Reply

3,853 Views
jeremyzhou
NXP Employee
NXP Employee

Hi Arun Muthuganesh,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
Jump-address command requires the address of the image vector
table (IVT). IVT can be part of the image or can be downloaded separately.
According to your description, the XYZ.bin don't consist the IVT, so the  
Jump-address command fails.
The post demonstrates how to generate the bootable image which contains IVT.

Have a great day,
TIC

 

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

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
Reply