AM2432: sbl_uart_uniflash failed to load sbl_qspi bootloader with SYS_REG failure

Hello,

Hong Zhang said:

So the setup is sbl_uart_uniflash and sbl_ospi (from SDK 09.00 and minimum change is done to use our flash) with SYSFW from SDK 10.0. 

Thanks for pointing this out.

Just by the look of it, there are three commands in your config file.

Now, after first one, you are seeing problems at second one which is your bootloader: sbl_ospi _sysfw_10.hs_fs.tiimage

I just want to know few things:

1. Do you see this flashing error every single time? Or sometimes all the 3 images are flashed via the UART Uniflash command?
2. Do you have a JTAG connected? If yes, then we can see where this gets stuck at in the bootloader by using the traditional loop_forever(). [I am pretty sure you know how to induce loop forever and debug if asked to based on our previous calls and debug experience]

Regards,

Vaibhav

Hello Vaibhav, 

Thanks  a lot for the reply.  

Answer your questions inline as below, 

1. Do you see this flashing error every single time? Or sometimes all the 3 images are flashed via the UART Uniflash command?
   Yes, I do see this error every single time. 
2. Do you have a JTAG connected? If yes, then we can see where this gets stuck at in the bootloader by using the traditional loop_forever(). [I am pretty sure you know how to induce loop forever and debug if asked to based on our previous calls and debug experience]
   I understand what you asked here, but I have multiple tasks on my side. I might take some time to get to this JTAG debugging. Given the error code is >> SYS_REG, I think this error code is generic. Some experts on TI side should be familiar with this issue.  Could you please help to check what does this error code mean to speed up our debugging process? 

Thanks a lot, 

Hong 

Hello Hong-san,

Thanks for your patience.

This is jut here for a reference: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1219281/faq-am2434-error-with-using-sbl-with-am243-evms-lp-am243-tmds243evm

Hong Zhang said:

Yes, I do see this error every single time.

I do understand that this issue is persistent.

To isolate the issue on top level, can you remove the sysfw(from SDK 10) binaries, and run the script, does it run in this case?

Looking forward to your response.

Thanks,

Vaibhav

Hello Vaibhav, 

When removing the sysfw (from SDK 10), it didn't report this error, and passed to program the FW into bootflash. 

Thanks, 
Hong 

Hi Hong,

Hong Zhang said:

When removing the sysfw (from SDK 10), it didn't report this error, and passed to program the FW into bootflash. 

So with earlier sysfw it passes and with the addition of sysfw 10.0 it does not. 

Allow me sometime to follow up here with another expert.

Regards,

Vaibhav

Hello Hong,

Can you please list the steps you did/performed to apply the SYSFW 10.0? A detailed one would be helpful for me to see if the steps were correct or not.

Regards,

Vaibhav

Hello Vaibhav, 

The way I did to use SYSFW 10.0 is to copy the SYSFW from the folder C:\ti\mcu_plus_sdk_am243x_09_00_00_35\source\drivers\sciclient\soc\am64x_am243x into folder C:\ti\mcu_plus_sdk_am243x_10_00_00_20\source\drivers\sciclient\soc\am64x_am243x , 

and recompile the project. 

Hong 

Hi Hong,

Hong Zhang said:

The way I did to use SYSFW 10.0 is to copy the SYSFW from the folder C:\ti\mcu_plus_sdk_am243x_09_00_00_35\source\drivers\sciclient\soc\am64x_am243x into folder C:\ti\mcu_plus_sdk_am243x_10_00_00_20\source\drivers\sciclient\soc\am64x_am243x , 

and recompile the project. 

This works and is the correct way too.

SYSREG is not a commonly seen issue across different customer queries we had.  So we would need to put loop forever and debug this.

Regards,

Vaibhav

Hi Hong, Merril

I have unlocked the thread, but it will lock again in 24 hrs if there is no activity , so i recommend opening a new post if needed.

Please note that Vaibhav is out of office this week, so responses maybe delayed. 

Thanks Mukul!  Pinging the thread to keep it open.

Hello Vaibhav, 

Could you please help to test on TI side using sbl_uart_uniflash from SDK9.0 using SYSFW 10.0 to see whether it passes on your side?

Thanks, 
Hong 

Hi Hong,

Could you please share the SBL_UART_UNIFLASH image with which you are seeing the issue?

BR, Prashant

Hello TI team, 

Could TI try to reproduce this issue without using our SBL_UART_UNIFLASH image? I don't think our minimum change would affect the result here. 

Steps to reproduce: 
1) Build SBL_UART_UNIFLASH from SDK 09.00.00.35 release + SYSFW binary from SDK 10.00.00.20  
2) Run uart_uniflash.py with SBL_UART_UNIFLASH + SBL_OSPI (from SDK 09.00.00.35 release) + hello_world_app image 
The above step should fail the same way. 

Thanks, 
Hong 

Hi Hong,

I had already tried the exact steps, which did not reproduce the issue, before my previous response. Then only I asked for the SBL_UART_UNIFLASH image.

The intention was to check for the string "SYS_REG" in your SBL_UART_UNIFLASH image.

The point is the ">>> SYS_REG" is a very particular string which must be coming from somewhere. I have searched all the MCU+ SDK and SYSFW code but could not find any such string.

So, the forward path here is if you could share the SBL_UART_UNIFLASH image built with TI Flash configurations then I could give that a try on the TI EVM.

Regards,

Prashant

Hello Prashant, 

I found this in our image, which is the part of the test code that is added for debugging SYSLOG print part. 

The interesting part is that why the sbl_uart_uniflash doesn't like this sbl_qspi with a SYSFW from SDK 10 for this part. 



Thanks, 
Hong 

Hi Hong,

Hong Zhang said:

The interesting part is that why the sbl_uart_uniflash doesn't like this sbl_qspi with a SYSFW from SDK 10 for this part. 

I don't think the issue is related to the SBL_QSPI as from the SBL_UART_UNIFLASH perspective any image to be flashed is just a raw data.

I believe the ">>> SYS_REG" is coming from the SBL_UART_UNIFLASH image itself. This is also evident by the fact that the python script received the ">>> SYS_REG" string even before it could send the SBL_QSPI image.

I am not sure why you have these SYS_REGISTER, SMPK, BMPK prints in the UNIFLASH example. Since it uses UART0 for receiving the images to be flashed, you must not use the UART0 for DebugP_log prints.

Regards,

Prashant