AM6526: An issue with using the Uniflash tool on Sitara AM6526 SR2.1.

Hi Novica,

Please provide the following details:

1) Is there any difference between working and non-working board other than different silicon revision?
2) Please confirm if SR2.1 is HS or Non-HS silicon
3) Have you modified the flash programmer for your custom board?

Regards,
Parth

Hi Parth,

1) Is there any difference between working and non-working board other than different silicon revision?

No, the schematic and PCB are the same. The silicon is the only component that is different between boards

2) Please confirm if SR2.1 is HS or Non-HS silicon

I can confirme that we have Non-HS silicon on our boards (see picture below)

3) Have you modified the flash programmer for your custom board?

The only modification that we did is adding support for the QSPI NOR flash memory that we have on our board. We didn't modify anything else.

With our modification, we can use the Flashwriter app and Uniflash tool without any problem on boards that have AM6548 SR2.0. But as I described in my previous post we have a problem with SR2.1.

Currently, we are using SDK6.03., and in this SDK version we added support for our custom board. But to do some further tests I installed SDK version 8.0. (pdk_am65xx_08_00_00_36) which does not contain any of our modifications.

Then I tried to use the Flashwriter application from SDK 8.0. and I can confirm that after loading the Flashwriter application to SR2.1. I have the same problem when I tried to send the SYSFW header as I explained above.

I made the same test on SR2.0. with  Flashwriter application from SDK8.0 and I can confirm that receiving xmodem header frame and loading of SYSFW to M3 core works normally.

Regards,

Novica

Hi Novica,

Can you try following and see if this works:

1) Change the boot mode settings to No-boot mode
2) Load and run your modified flash programmer "uart_am65xx_cbs_flash_programmer.tiimage" on R5 using CCS.
3) Make sure you are getting "ccc" printed on mcu console once you run the binary.
4) Load SBL, SysFW and appimage at required offset using uniflash.

Basically, you'll be using CCS to run flash_programmer instead of uniflash, but everything else remains same.

Regards,
Parth

Hi Parth,

I did the steps that you proposed:
1) I changed the boot mode settings to No-boot mode
2) The initialization of SoC was done through CCS (by using .js and GEL files)
3) Then I loaded "uart_am65xx_cbs_flash_programmer.tiimage" on R5
4) At first, I didn't detect that character 'C' was printed on MCU UART, but then I saw and character 'C' is printed on baud rate 230400 bit/s
5) In the case when the baud rate is 230400 bit/s, I can not use the Uniflash application on the PC side, because the Uniflash application on PC expects that character 'C' is sent on a baud rate of 115200 bit/s. But anyway I made a workaround. First I used Docklight to send xmodem header frame and then I am using ExtraPutty (sending of file with xmodem protocol) to send an image that I want to write to NOR flash and I can confirm that I can write images (SBL, SYSFW, and APP) to NOR flash successfully.

The other approach that I used is to debug the Flashwriter application in the original environment on SoC (ROM bootloader is doing basic initialization of SoC)
1) I changed the boot mode settings to UART-boot mode
2) I am getting "ccc" printed on MCU console (sent by ROM bootloader) on a baud rate of 115200
3) Then I use ExtraPutty to send "uart_am65xx_cbs_flash_programmer.tiimage" via xmodem protocol to ROM bootloader
4) Then I created debug configuration in CCS (without calling the .js file). I run this configuration and connect to the R5 core
5) Then I loaded the symbols for "\uart_am65xx_cbs_flash_programmer.out" so I can do some debugging
6) I am getting "ccc" printed on MCU console (sent by Flashwriter application) on baud rate of 115200
7) The next step is to send SYSFW to Flashwriter app on R5 core, so Flashwritter can load SYSFW to M3 core
8) In this step I can confirm that header that is received on the R5 core (this header contains information that the image that is sent after this header is SYSFW and it must be loaded to the M3 core) on MCU_UART have some bytes that are overwritten with 0x00. When the wrong header is detected the Flashwriter application goes to abort function

7) I did compare MCU UART registers content between SR2.0. and SR2.1. and I didn't detect any differences. On both boards I did check UART registers content before and after the SYSFW header frame is sent

We have the same problem with all bords that have SR2.1. silicon.

Do you have a board with AM6526BACDXA silicon on your side, can you try to do the same tests as I did?

Regards,
Novica

Hi Novica,

Novica Jovanovic said:

Do you have a board with AM6526BACDXA silicon on your side, can you try to do the same tests as I did?

Unfortunately, I do not have any board with SR2.1 on my end.

Novica Jovanovic said:

At first, I didn't detect that character 'C' was printed on MCU UART, but then I saw and character 'C' is printed on baud rate 230400 bit/s

Did you change anything with respect to the clock fed to UART module?

Regards,
Parth

Hi Parth,

Parth Nagpal said:

Did you change anything with respect to the clock fed to UART module?

No, I didn't change anything with respect to the clock on UART. You can check and confirm this "issue" on your side with any Sitara AM65xx board.

Parth Nagpal said:

Unfortunately, I do not have any board with SR2.1 on my end.

I think it would be good and necessary to include in the conversation some of your colleagues who have a board with AM6526BACDXA silicon.

As I mentioned I have bords with SR2.0. and SR2.1. silicon on my side. We do not have any problem with SR2.0. but with SR2.1. boards the only problem that we have is when we use Uniflash (when we boot the application directly from UART or when we load our application directly with JTAG then we did not detect any problem)

Regards,
Novica

Hi Novica,

Novica Jovanovic said:

At first, I didn't detect that character 'C' was printed on MCU UART, but then I saw and character 'C' is printed on baud rate 230400 bit/s

Are you seeing this behavior with with SR 2.0 as well?

Also, I am checking internally if someone has access to SR 2.1. We should have some update by Monday.

Regards,
Parth

Hi Parth,

Parth Nagpal said:

Are you seeing this behavior with with SR 2.0 as well?

Yes,  if initialization of SoC (on SR2.0. or SR2.1.) is done by using GEL files and .js files, the character 'C' is printed on baud rate 230400 bit/s. But I think this is a known "issue" on your side.

So to avoid this problem, when we want to do some debugging we are using the second approach. First, we load Flashwritter via xmodem protocol to the R5 core and then we create a debugger configuration in CCS that simply "attaches" to the processor, without any initializing GEL files. 

Parth Nagpal said:

Also, I am checking internally if someone has access to SR 2.1. We should have some update by Monday.

Great! We will use Sitara (AM6526BACDXA) for serial production, so solving this issue is really important and critical for us.

Regards,
Novica

Hi Novica,

Novica Jovanovic said:

Yes,  if initialization of SoC (on SR2.0. or SR2.1.) is done by using GEL files and .js files, the character 'C' is printed on baud rate 230400 bit/s. But I think this is a known "issue" on your side.

I tested this with SR 2.0 and processor_sdk_rtos_am65xx_6_03_00_106 and I don't see this issue. I can see the character "c" printing at 115200. Are you sure there is nothing changed with respect to clock fed to UART?

Regards,
Parth

Hi Parth,

Parth Nagpal said:

I tested this with SR 2.0 and processor_sdk_rtos_am65xx_6_03_00_106 and I don't see this issue. I can see the character "c" printing at 115200. Are you sure there is nothing changed with respect to clock fed to UART?

In GEL files we only changed the clock of the DDR controller, but nothing else was changed. 

We also have the IDK board with Sitara SR1.0.

I made the same test on the IDK board as I did on our custom board with SR2.1 and SR2.0
1) I changed the boot mode settings to No-boot mode
2) The initialization of SoC was done through CCS (by using original .js and GEL files)
3) Then I loaded "uart_am65xx_idk_flash_programmer.tiimage" on R5
4) Then I saw and character 'C' is printed on baud rate 230400 bit/s

So the conclusion is that when I use the original GEL files for the IDK board and when initialization of SoC is done via .js and GEL files then the baud rate on MCU UART is 230400 bits/s, the same as on our custom board with SR2.0. and SR2.1.

Did you manage to get a board with Sitara SR2.1, so we can together analyze the problem that we have on our boards with SR2.1.? 

Regards,
Novica

Hi Novica,

Novica Jovanovic said:

Then I loaded "uart_am65xx_idk_flash_programmer.tiimage" on R5

You should load uart_am65xx_evm_flash when you are using SR1.0, but anyways loading uart_am65xx_evm_flash is also printing C at 11500 for me.

Novica Jovanovic said:

The initialization of SoC was done through CCS (by using original .js and GEL files)

Which CCS version are you using?

Novica Jovanovic said:

Did you manage to get a board with Sitara SR2.1, so we can together analyze the problem that we have on our boards with SR2.1.? 

Sorry, no one seems to have SR2.1 here. I am looking for it, will let know if I get access to it,

Regards,
Parth

Hi Parth,

Parth Nagpal said:

Which CCS version are you using?

I am using CCS 9.2.

I have one update regarding the "issue" when flashwritter application is loaded with CCS. When I changed the boot mode settings to No-boot mode on the IDK board,  one of the boot switches still remained in the ON position and that is the reason I had a 230400 baud rate instead of 115200. Now when i fixed this switch I have no more problems with the wrong baud rate on IDK and on our custom board.

Now when No-boot mode is set properly and when I load and run our modified flash programmer "uart_am65xx_cbs_flash_programmer.tiimage" on R5 using CCS, I can write images to NOR flash without any problem (on SR2.0 and SR2.1)

But still, we have the issue with SR2.1. after the flash programmer is loaded via MCU UART (basic initialization is done by ROM bootloader) then we have the problem as I described in my first post.

Novica Jovanovic said:

I tried to debug this problem. After the Flashwriter app is loaded to R5 core, I used XDS200 to connect to the R5 core and I am seeing that each time when the frame is received some of the received bytes are overwritten with 0x00 so checking of CRC failed and the application crash on R5 core.

I hope that you will manage to get access to the board with SR2.1. soon. Until you get it, write me if you have any more ideas about what to try next.

Regards,
Novica

Hi Parth,

Do you have some news about our topic?

Regards,
Novica

Hi Novica,

Sorry, I am not yet able to arrange a board with SR2.1 on my end. Still looking for it.

Regards,
Parth

Hi Novica 

We regret the delay on this. We will be getting hold of SR2.1 EVM/IDK early next week and can start looking at this again to help you with the issue. 

If you have any additional updates - please feel free to share.

Regards

Mukul 

Hi Mukul,

Thanks for taking care of this issue.

I do not have any additional updates, but feel free to ask if you need any additional information from our side.

Regards,
Novica

Hey Novica,

My name is Andrew and I would be more than happy to assist you with this!  I have been investigating your problem extensively, and I am excited to report that I have successfully flashed the proper SBL binary, using the same silicon revision evm as you, with Uniflash version 6.1.0, pdk_am65xx_1_0_7. Here is the procedure I employed on Windows:

C:\ti\uniflash_6.1.0\processors>ProcessorSDKSerialFlash -c COM23 -f FlashWriter\am65xx_idk\uart_am65xx_idk_flash_programmer.tiimage -i 0

----------------------------------------------------------------------------
ProcessorSDKSerialFlash CLI Tool
Copyright (C) 2017-2020 Texas Instruments Incorporated - http://www.ti.com/
Version 1.3.0.0
----------------------------------------------------------------------------
Downloading Flash Programmer..

Transferring File of size 161612 bytes
File Transfer complete!

Enabling SysFw transfer!!!
Header Transfer complete
Transferring System Firmware..
Transferring File of size 263072 bytes
File Transfer complete!

C:\ti\uniflash_6.1.0\processors>ProcessorSDKSerialFlash -c COM23 -f C:\ti\pdk_am65xx_1_0_7\packages\ti\boot\sbl\binary\am65xx_idk\ospi\bin\sbl_ospi_img_mcu1_0_release.tiimage -d 3 -o 0

----------------------------------------------------------------------------
ProcessorSDKSerialFlash CLI Tool
Copyright (C) 2017-2020 Texas Instruments Incorporated - http://www.ti.com/
Version 1.3.0.0
----------------------------------------------------------------------------
Transferring the Image to Flash Programmer..

Transferring Header Information..
Header Transfer Complete!

Flashing Image of size 136135 bytes
Flash Programming Success!

After reviewing this thread, I do have one question, which version of Uniflash are you using? 

Best regards,

Andrew

Hi Andrew,

Thanks for all help you can provide in resolving this issue

Andrew Shutzberg said:

After reviewing this thread, I do have one question, which version of Uniflash are you using? 

We are using Uniflash versions 6.1.0 and 6.4.0. But as you can see from the previous posts we have our custom board with AM6548 SR2.0. and AM6526 SR2.1 (the only difference between boards is in the silicon). On the board with AM6548 SR2.0. we can use Uniflash without any problem and on board with AM6526 SR2.1. we have the problem described in more detail above.

Maybe the following information will be useful for you:
1) Boot pins on our custom board are set in the following way: (we are using NOR flash as the primary boot device and UART as the backup boot device)
BOOTMODE<0> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<1> = 1 (Pull-Up with 1K Ohm)
BOOTMODE<2> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<3> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<4> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<5> = 1 (Pull-Up with 1K Ohm)
BOOTMODE<6> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<7> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<8> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<9> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<10> = 1 (Pull-Up with 1K Ohm)
BOOTMODE<11> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<12> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<13> = 1 (Pull-Up with 1K Ohm)
BOOTMODE<14> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<15> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<16> = 0 (Pull-Down with 100K Ohm)
BOOTMODE<17> = 1 (Pull-Up with 1K Ohm)
BOOTMODE<18> = 0 (Pull-Down with 100K Ohm)

MCU_BOOTMODE<0> = 1 (Pull-Up with 1K Ohm)
MCU_BOOTMODE<1> = 1 (Pull-Up with 1K Ohm)
MCU_BOOTMODE<2> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<3> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<4> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<5> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<6> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<7> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<8> = 0 (Pull-Down with 100K Ohm)
MCU_BOOTMODE<9> = 1 (Pull-Up with 1K Ohm)

2) On our custom board, we only have the 25MHz WKUP oscillator (we do not use OSC1 and WKUP_LFOSC)

3) I read Silicon Revision Register and in the picture below you can see the content of this register

 I made the test again and I can confirm that our custom board with SR2.1. always failed at beginning of loading of SYSFW.

Maybe you can try to set boot pins on your EVM board with AM6526 SR2.1. as we did on our custom board, and then you can do a test. If that test passes without any problem then the second option is to temporarily desolder OSC1 and WKUP_LFOSC and leave only the WKUP oscillator and then try to do the test again.

Many thanks and best regards,
Novica

Hey Novica,

Thanks for the additional information, I have relayed this to the team and we are investigating further.  I am expecting a response within the next 1-2 business days.  In the meantime, please feel free to reply here if there are any further updates on your end.

Best regards,

Andrew

Hey Novica,

So I tried the bootmode setup you are using, on the SR2.1 revision evm you are using, and still don't see the error you encountered.  I know earlier in the thread you mentioned using a baud rate of 230400, is this still the case or in your latest response were you using 115200? Also, is there currently a Linux SD card inserted in the board? 

In your latest reply, you mentioned Uniflash 6.1 and 6.4, are you saying the error being encountered is the same with each version?

Best regards,

Andrew

Hi Andrew,

Andrew Shutzberg said:

So I tried the bootmode setup you are using, on the SR2.1 revision evm you are using, and still don't see the error you encountered.  I know earlier in the thread you mentioned using a baud rate of 230400, is this still the case or in your latest response were you using 115200? Also, is there currently a Linux SD card inserted in the board? 

So the issue with the wrong baud rate occurred when I try to load flashwriter application via CCS, but this does not represent an issue anymore for us, now I can load flashwriter application to R5 core, and then I can use the Uniflash tool to write the image to NOR flash without any problem on our custom board with SR2.1.

But we still have the issue after flashwritter application is loaded by ROM bootloader!

Novica Jovanovic said:

We are using the Uniflash tool to write images (SBL, SYSFW and APP) to NOR flash, and we didn't have any problem using this tool on our board with SR2.0. 

But on boards with SR2.1. the Uniflash tool does not work. When Flashwriter application is loaded to R5 core, the problem occurs when sysfw header frame is sent then the target responded with 0x18.
The other strange thing on SR2.1. is while receiving the header sequence, in parallel the R5 is sending character 'C' (0x43), and the problem with that is that this sending is not triggered by Flashwritter application on R5. (see picture below)

The problem occurs when sysfw header frame is sent from the PC (uniflash tool) then the target responded with 0x18, more details you can find in my first posts above. You can see from the logic analyzer which data are sent on the UART line and what is received on the Sitara side on the board with SR2.1.

Novica Jovanovic said:

So the problem on the board with SR2.1. is that some bytes that are received on MCU_UART are corrupted.

On boards with SR2.0. we don't have this issue, but on all boards with SR2.1 we have this issue, and the silicon is the only component that is different between boards.

Andrew Shutzberg said:

In your latest reply, you mentioned Uniflash 6.1 and 6.4, are you saying the error being encountered is the same with each version?

We have the same behavior with both Uniflash tool versions. From my point of view, this problem is not related to the version of Uniflash tool, it is related to the Sitara SR2.1 in the step after ROM bootloader finished loading of flashwriter application, the problem occurs in the first received xmodem frame  (the bad CRC is detected and the target board respond with 0x18)

Best regards,

Novica

Hey Novica,

Thank you for the additional information and your patience.  We are still investigating this issue, but we expect to have an update early next week.

Best regards,

Andrew

Hi Andrew,

We received new samples of SR2.1. silicon for our boards. Below is given a picture of the top of the SoC/package:
\

On the boards with this SR2.1. silicon (AM6526BACDXEAF) we can flash our boards with the Uniflash tool without any problem!

On the boards with "older" SR2.1 silicon (AM6526BACDXA, see picture below), as you know we have the problem that I described above in my previous posts.

So my question is can you check internally what is the differences between this two SR2.1. silicone?

Best regards,

Novica

Hello Novica, 

Thank you for the note.

Let me check internally if there is some information.

Regards,

Sreenivasa

Hello Novica, 

Please note the delay in reply from our side.

I am checking internally on how we could support. One of the question that could come up is on the numbers of samples tested. Could you please provide your inputs.

Regards,

Sreenivasa

Hello Kallikuppa 

We are experiencing the Same problems as well.

We have 5 boards with the same CPU(AM6526BACDXA) with the same problems.

help would be appreciated!

Kind Regards,
Heayoung

Hello Heayoung

Thank you for the note.

Let me check and update.

Regards,

Sreenivasa

Hello Sreenivasa,

Sorry for the delay in replay.

We have 6 boards with the "older" SR2.1. SoC (AM6526BACDXA), and each of them has the same problem.

Regards,
Novica

Hello Novica,

No problems and thank you for the inputs. This helps. 

Let me check and update.

Regards,

Sreenivasa

Hello Novica,

Please refer to the below note:

We are using the Uniflash tool to write images (SBL, SYSFW and APP) to NOR flash, and we didn't have any problem using this tool on our board with SR2.0.

Would it be possible for you to share a picture of the device for the SR2.0.

Regards,

Sreenivasa

Hello  Sreenivasa,

Sorry for the delayed reply.

The SR2.0. silicon that we have on our boards has the following mark (X6580AACD):

Regards,

Novica

Hello Novica,

Thank you for the input.

Regards,

Sreenivasa

Hello Novica, 

 I assume the picture you shared is for the below

On the board with AM6548 SR2.0. we can use Uniflash without any problem

Regards,

Sreenivasa,

Hello  Sreenivasa,

Kallikuppa Sreenivasa said:

 I assume the picture you shared is for the below

On the board with AM6548 SR2.0. we can use Uniflash without any problem

Yes, you are right, the picture refers to the board with AM6548 SR2.0.

Regards,

Novica

Hello Novica, 

Noted and Thank you.

Regards,

Sreenivasa

Hello  Sreenivasa,

Do you have any updates about this topic?

Regards,
Novica

Hello Novica, 

Thank you for following.

We are internally reviewing based on the available information.

Let me check internally and update you.

Regards,

Sreenivasa

Hello Novica, 

We are internally reviewing based on the available information.

I will update you based on the analysis.

Regards,

Sreenivasa

Hello Novica, 

We are internally reviewing based on the available information.

I still do not have an update to share.

I assume this is not stopping any of the development on your side. 

Regards,

Sreenivasa