AM2432: What is the difference between primary UART boot mode and backup UART boot mode?

Hello,

Can you please share the successful flashing logs from the backup UART bootmode for comparison purposes?

In any case, this doesn't look like a bootmode or UART issue. The images are at least being received by SBL_UART_UNIFLASH over UART but something goes wrong while flashing the received images.

The error is mostly originating from the following snippet

Regards,

Prashant

Hello Prashant, 

I debugged this further based on the feedback from the co-debugging session. 

Board_flashopen() always failed with -1 as status return when the primary boot is UART instead of SPI. 
Status is -1 ,  

It seems in our case, we have to rely on bootRom to init OSPI in SPI primary boot mode before we can access the OSPI flash.  Could you please help us to understand what bootROM do to initi OSPI bus, so that we can leverage those parts in our code implementation? 

Thanks, 

Hong 

Hello Prashant, 

I did probe the signals via scope, and I only observed CLK, CS, but there is no data present. I think we still miss some configurations, but I don't know where it could be missed here. Because the same configuration works when SPI is the primary boot mode.  Somehow, our code relies on bootROM to configure the OSPI bus. 

Thanks,

Hong 

Hello Hong,

Hong Zhang said:

Board_flashopen() always failed with -1 as status return when the primary boot is UART instead of SPI. 
Status is -1 ,  

Inside the board flash open there are a whole bunch of steps where it could be failing, can you narrow it down to its very end and tell us where exactly it is getting status as -1.

Regards,

Vaibhav

Hello Vaibhav, 

It failed at readID in Board_flashopen. See the read marked comment as below. 

Thanks, 
Hong 

static int32_t Flash_norOspiReadId(Flash_Config *config)
{
int32_t status = SystemP_SUCCESS;
Flash_NorOspiObject *obj = (Flash_NorOspiObject *)(config->object);
Flash_DevConfig *devCfg = config->devConfig;
FlashCfg_ReadIDConfig *idCfg = &(devCfg->idCfg);

uint8_t idCode[FLASH_OSPI_JEDEC_ID_SIZE_MAX] = {0};
uint32_t cmdAddr = OSPI_CMD_INVALID_ADDR;
uint32_t dummyBits = 0;
uint32_t idNumBytes = 3;
uint32_t numAddrBytes = 0;

if(obj->currentProtocol == FLASH_CFG_PROTO_8D_8D_8D)
{
dummyBits = 4;
cmdAddr = 0U;
numAddrBytes = obj->numAddrBytes;
idNumBytes = 4; /* Can't read odd bytes in octal DDR */
}
else
{
/* default config */
}

status = Flash_norOspiCmdRead(config, idCfg->cmd, cmdAddr, numAddrBytes, dummyBits, idCode, idNumBytes);

/* Verify ID with filled data */
if (status == SystemP_SUCCESS)
{
uint32_t manfID, devID;

manfID = (uint32_t)idCode[0];
devID = ((uint32_t)idCode[1] << 8) | ((uint32_t)idCode[2]);
if (!((manfID == config->attrs->manufacturerId) && (devID == config->attrs->deviceId)))
{
/* Try the other 3 bytes */
manfID = (uint32_t)idCode[3];
devID = ((uint32_t)idCode[4] << 8) | ((uint32_t)idCode[5]);
if (!((manfID == config->attrs->manufacturerId) && (devID == config->attrs->deviceId)))
{
status = SystemP_FAILURE;   => failed at here, because the read manfID and devID are all 0s (failed to read). 
}
}
else
{
/* Success, nothing to do */;
}
}

Hi Hong,

Could you please clarify the following doubt before we jump into the OSPI stuff?

So, in your other thread discussing the flashing via USB DFU, the flashing at least is happening successfully. Assuming that the procedure is done over USB DFU primary bootmode, may I know what is different in the DFU flashing procedure than the UART flashing procedure that it is failing in the UART but not in DFU while in both cases the ROM won't touch the flash at all?

Thanks!

Hello Prashant, 

Thanks for your reply. 

For the other thread discussing the flashing via USB DFU, USB boot mode is not primary boot mode. We have SPI as primary boot mode and USB boot as backup boot mode. Since the SPI flash is empty, it falls back to USB boot as backup boot mode. 

Hong 

Hi Hong,

Thanks for the clarification! So, I guess there will be issues with DFU flashing as well when done over USB DFU primary bootmode.

I have one more clarification to ask because of one inconsistency in your previous findings.

So, you initially reported the following failure

Command arguments : --file=bootloader_am243_debug.hs_fs.tiimage --operation=flash --flash-offset=0x0
Sent bootloader_am243_debug.hs_fs.tiimage of size 366468 bytes in 36.7s.
[STATUS] ERROR: Flashing failed !!!

If we trace the SBL_UART_UNIFLASH execution, this tells us that the execution must have gone at least past the Board_driversOpen call so that it could start the XMODEM server, receive the image, & then only somehow fails in flashing the image.

However, then you reported that the Board_flashOpen() call is returning FAILURE. If that is the case then it is contradicting the previous observation since the Board_driversOpen() will return FAILURE & the execution will get trapped in the DebugP_assert statement. This means the execution won't reach to the point where it could start the XMODEM & at least receive the image.

status = Board_driversOpen();
DebugP_assert(status == SystemP_SUCCESS);

Can you please once review the setup & clarify what exactly is the issue?

Thanks!

Hello Prashant, 

This is a very good question.  

When it original failed at the following status, there is no debug code to add to tell where it actually failed. 
[STATUS] ERROR: Flashing failed !!!

Adding further debug code to print out the error code for where it actually failed, it seems that it failed at even earlier state than before. 

Hong 

Hi Hong,

Hong Zhang said:

Adding further debug code to print out the error code for where it actually failed, it seems that it failed at even earlier state than before.

That is interesting. Can you share where these debug prints are added?

Apart from this, what changes you have done till now in the SBL_UART_UNIFLASH to make it compatible with your custom flash part? If possible, please share the full example itself.

Regards,

Prashant

Hello Prashant, 

For the sbl_uart_uniflash project, I was not able to use UART debug log print, because the UAR1 is not available on our board. Is there a way that we can get the error log from the error log zone?  

What I did instead is the load sbl_uart_uniflash project first, then re-load the same project (commented out 
Bootloader_socWaitForFWBoot();Bootloader_socOpenFirewalls();Bootloader_socNotifyFirewallOpen();)from JTAG via CCS ( sbl doesn't work directly via JTAG without sbl booting on HS-FS part).  Without disabling the bootloader function, the JTAG loading doesn't work.  The test sequence difference might cause the different failure behavior above. 


I shared the custom bootflash change via email, thanks!

Hong

Hi Hong,

Thanks for the explanation!

This explains the contradicting behaviours as the debugging procedure is incorrect. The SBLs has to be debugged using a certain procedure as documented in the following FAQ

(+) [FAQ] AM62X/AM64X : [FAQ] Debugging SBL boot in RTOS SDK - Processors forum - Processors - TI E2E support forums

I will come back to how to proceed with debugging the failure with SBL_UART_UNIFLASH.

First, can you confirm this is the only failure seen when no debugging produre is followed & the failure is consistent

Command arguments : --file=bootloader_am243_debug.hs_fs.tiimage --operation=flash --flash-offset=0x0
Sent bootloader_am243_debug.hs_fs.tiimage of size 366468 bytes in 36.7s.
[STATUS] ERROR: Flashing failed !!!

Thanks!

Hi Hong,

Can you remove your modifications in the SBL_UART_UNIFLASH `main.c` file & try flashing with the following changes?

status = Board_driversOpen();
DebugP_assert(status == SystemP_SUCCESS);

/* Changes start here */
OSPI_norFlashSetCmds(0x03, 0x02, 0xD8);

OSPI_Handle ospiHandle = OSPI_getHandle(CONFIG_OSPI0);
OSPI_norFlashInit1s1s1s(ospiHandle);
/* Changes end here */

If this doesn't work then based on the fact that the 1s mode is pretty much standard for all flash parts can you try the following SBL_UART_UNIFLASH built with your flash part's ManId, DeviceId, & flash size.

sbl_uart_uniflash.debug.hs_fs.tiimage

Regards,

Prashant

Hello Prashant, 

I removed the modification in the SBL_UART_UNIFLASH `main.c` and added the change that you suggested above, but it didn't yield CCCC to allow to input next file. 

I did try to rebuild sbl_uart_uniflash with your flash part's ManId, DeviceId, & flash size using json file, but failed the same way.

Is there a debug method that can be used for sbl_uart_uniflash to print error code, given we don't have uart1 available? 

Hong 

Hi Hong,

You could use printf for now and the CCS console should most probably show it. Make sure to include stdio as well.

Other way could be to add another UART instance, instead of UART1, but can you first try with printf and check if it works to put out the logs on the CCS console.

Regards,

Vaibhav

Hello Vaibhav,

Use primary UART boot mode, I need to load the binary via UART0, and there is no CCS console available. I could not use JTAG because it is not in Dev boot mode, and JTAG is not enabled by default on HS-FS MCU.


Hong

Hello TI team, 

The following code could not read any manufID and deviceID out when the board is put into the Primary UART boot mode on our board. We don't have flash part reset pin connected to a GPIO, what we need to do to be able to read the device ID?  I believe this only requires the pinmux to be configured and doesn't depend on any other JSON configs, but it still failed. 

OSPI_Handle ospiHandle = OSPI_getHandle(CONFIG_OSPI0);

OSPI_norFlashSetCmds(0x03, 0x02, 0xD8);
// Initialize the SPI nor bootflash in 1s-1s-1s mode
err = OSPI_norFlashInit1s1s1s(ospiHandle);
if (err < 0) {
return kBootFlashInit;
}

err = OSPI_norFlashReadId(ospiHandle, &manufID, &deviceID);
if (err < 0) {
return kBootFlashReadID;
}

Thanks, 
Hong 

Hello TI team, 

I noticed that SBL_UART_UNIFLASH requires to configure MMCSD bus, but we don't have SD card interface in our design. Removing this interface could cause the project to fail to compile. How should we configure this interface if we don't use it?  Does this also mean that we cannot use any pins on this interface for other functionality? 

As below is the capture from SBL_UART_UNIFLASH from TI's SDK 09.00.00.35 release. 



Thanks, 
Hong 

Hi Hong,

Hong Zhang said:

err = OSPI_norFlashReadId(ospiHandle, &manufID, &deviceID);

We can debug this. Basically, the flash part you are using reads the device id and the manufacture id into this buffer called idCode. The idCode buffer can be seen when you step inside the API OSPI_norFlashReadID();

It would be helpful if you could let me know what is the cmd value being passed to OSPI_norFlashCmdRead(), and I also want to know the value stored in idCode after the OSPI_norFlashCmdRead() call.

Hong Zhang said:

I noticed that SBL_UART_UNIFLASH requires to configure MMCSD bus, but we don't have SD card interface in our design. Removing this interface could cause the project to fail to compile. How should we configure this interface if we don't use it?  Does this also mean that we cannot use any pins on this interface for other functionality? 

As below is the capture from SBL_UART_UNIFLASH from TI's SDK 09.00.00.35 release. 

Prashant can you help with the above, thanks.

Regards,

Vaibhav

Hello Vaibhav, 

The command value is defined by   OSPI_NOR_CMD_RDID, which is 0x9F. And the idCode was read to be 0, because it failed to read the idCode. 

I noticed that this only failed in sbl_uart_uniflash project, even if this read happens before any flash related code from Board_driversOpen was launched. The same code if it is located in sbl_uart_am243m project, it was able to read the device ID.  

For the same snap code as below, read ID would pass if the code is inserted in sbl_uart_am243 project, but it failed in sbl_uart_uniflash project.  I checked the System_init() and Drivers_open(), and didn't see any code that could contribute this issue. Any help is appreciated. 

System_init();
Drivers_open();

{
OSPI_Handle ospiHandle = OSPI_getHandle(CONFIG_OSPI0);

/* Zero init the dev defines struct */
memset(&gNorSpiDevDefines, 0, sizeof(gNorSpiDevDefines));

OSPI_norFlashSetCmds(0x03, 0x02, 0xD8);

/* Initialize the flash device in 1s1s1s mode */
OSPI_norFlashInit1s1s1s(ospiHandle);

/* Read ID */
status = OSPI_norFlashReadId(ospiHandle, &manfId, &deviceId);
}

Board_driversOpen();

Hong 

Hello Hong,

Let me read through your responses and come back here in sometime with a follow up action step.

Thank you for your patience.

Regards,

Vaibhav

Hello Hong,

Hong Zhang said:

System_init();
Drivers_open();

{
OSPI_Handle ospiHandle = OSPI_getHandle(CONFIG_OSPI0);

/* Zero init the dev defines struct */
memset(&gNorSpiDevDefines, 0, sizeof(gNorSpiDevDefines));

OSPI_norFlashSetCmds(0x03, 0x02, 0xD8);

/* Initialize the flash device in 1s1s1s mode */
OSPI_norFlashInit1s1s1s(ospiHandle);

/* Read ID */
status = OSPI_norFlashReadId(ospiHandle, &manfId, &deviceId);
}

Board_driversOpen();

So assuming that the initial code is same in both the cases: sbl_uart_uniflash and sbl_uart_am243, ot only fails to read the device id in sbl_uart_uniflash while in sbl_uart_am243 it is able to read the device id even before the Board_driversOpen() is called.

Is my understanding of the above statement correct?

Rgeards,

Vaibhav

>

So assuming that the initial code is same in both the cases: sbl_uart_uniflash and sbl_uart_am243, ot only fails to read the device id in sbl_uart_uniflash while in sbl_uart_am243 it is able to read the device id even before the Board_driversOpen() is called.

Is my understanding of the above statement correct?

Yes, your understanding is correct here. 

Hong 

Hello Hong,

Can you share the example.syscfg file for both of the projects? Or can you compare and check if the sysconfig flash configuration is correct for both the projects?

Please also check the OSPI tab configurations as well.

Regards,

Vaibhav

Hello Vaibhav, 

The main difference is that the flash is not configured in the sbl_uart project and I leverage the ospi_flash_diag.c added in this sbl_uart project to read flash ID, but sbl_uart_uniflash configured flash in sysconfig. 

Thanks, 
Hong 

Hello Hong,

Lets discuss further in our call today.

I would like to see few things like your sysconfig file, OSPI frequency and clock divider values and so on. 

I would also like to see the main.c code for sbl_uart_uniflash and sbl_uart_am243 projects and compare the initialization process.

Then we can plan the next action steps and I will post it here itself.

Regards,

Vaibhav

Hello Vaibhav, 

Thanks a lot for the reply.  I worked on this again last weekend, and listed the brief summary below. 

1) We are still waiting for the answer about why the sbl_uart_uniflash project requires the configuration of MMCSD0 interface. We don't use this bootable interface in our project. 
2) In the sbl_uart project, I added the opsi_flash_diag.c into this project and it was able to read flash ID properly. However as soon as I added the flash configuration inside the same project, it failed to read flash ID. Though the flash related code should have been done after ospi_flash_diag_main() based on the code below. But for some reason, after adding flash config into sysconfig, ospi_flash_diag_main() failed to read flash ID.  This issue only occurred for the case when UART is the primary UART boot. 

Drivers_open();

ospi_flash_diag_main(NULL);

status = Board_driversOpen();

Thanks, 
Hong 

There is another bug I noticed from TI's SDK SBL_QSPI project in ti_board_open_close.c file, the pageCount is not correct. 

Flash_Attrs gFlashAttrs_S28HS512T =
{
    .flashName = "S28HS512T",
    .deviceId = 0x5B1A,
    .manufacturerId = 0x34,
    .flashSize = 67108864,
    .blockCount = 256,
    .blockSize = 262144,
    .pageCount = 1024,
    .pageSize = 256,
    .sectorCount = 16384,
    .sectorSize = 4096,
};

Hi Hong and Team,

Thanks for joining the call.

Here are the meeting notes.

Hong Zhang said:

We are still waiting for the answer about why the sbl_uart_uniflash project requires the configuration of MMCSD0 interface. We don't use this bootable interface in our project. 

set card type to "no device".

Hong Zhang said:

Drivers_open();

ospi_flash_diag_main(NULL);

status = Board_driversOpen();

Before addition of flash config values:

Take a register dump of OSPI starting from 0FC4 0000h until 0FC4 00FCh.

After addition do the same thing and put out the values on E2E for us to be able to compare the changes(if any).

Also make sure after adding the flash values, to omit the ospi_flash_diag_main() and call drivers open and board drivers open. Then check if the failure still happens inside Board_driversOpen() while reading device id.

NOTE:

Please check on the possibility of sending the example.syscfg file for both the projects that is sbl_uart_uniflash and sbl_uart_am243.

Regards,

Vaibhav

Hello Vaibhav, 

I did register dump for the OSPI register values for the case that ospi_flash_diag_main() is able to read the ID register, and the case that the same code fails to read the ID register after adding flash config in sysconfig. The register values are exactly the same. 


Thanks,
Hong 

Hong

We are planning to setup another debug call this week, while we do that, can you please get the sign off from your security team so that you can share your screen during the meeting and we can directly debug on your setup?

Regards

Karan

Hello Karan, 

Yes, we got permission that we can discuss over Zoom meeting.  I can send out a Zoom meeting invite once I know what time works for TI side. 

Thanks, 
Hong 

Hello Hong,

We can schedule a call for Friday IST 6:30 pm onwards. Please send out a zoom invite link via mail (vaibhavk@ti.com)

Regards,

Vaibhav

Hello Hong,

Here is another experiment I want you to run.

So before our call, I would like you to run through this table.

The result1 if it is same as result2 then we need to look for other pointers, but if not, then we will have our way through the debug and figure out a solution.

Regards,

Vaibhav

Hong, Vaibhav

Please setup a call for tomorrow as Friday is a holiday in TI India.

Regards

Karan

Hello Hong,

Please make sure to run through these experiments before the call: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1408607/am2432-what-is-the-difference-between-primary-uart-boot-mode-and-backup-uart-boot-mode/5452995#5452995

Also schedule a call as per Karan's recommendation tomorrow 6:30 pm IST would be nice.

NOTE: If you put out the results of running the suggested experiment then we can look into it before the call and give pointers as well.

Regards,

Vaibhav

Hello Vaibhav, 

I just setup a Zoom meeting invite for Thursday morning (EST time 9 am). 

I did further look into this issue, and compared the case sbl_uart with added ospi_diag (working case) with the case sbl_uart with added ospi_diag and flash config in sysconfig (failure case), and noticed there is difference in the SYSCONFIG file.   For the working case, the example.sysconfig configured all the 8 OSPI data pins, but for the failed case, only the first three pins that are necessary for the 1s-1s-1s mode are configured. 

Further, I added all the 8 pins configuration to the example.sysconfig of sbl_uart_uniflash, which worked as well for the primary UART boot mode. 

Could TI help me to understand why the spare OSPI pins are required to be configured for the primary UART boot mode case, but not for the backup UART boot mode case? 

In addition, I would like to further discuss the QSPI pin reset suggestion as you posted before. For our latest schematic, we do have this pin connected in our design, but not in our previous design. I would like to understand TI's suggestion about this QSPI pin reset. 

Thanks, 
Hong 

Hello TI team, 

Our HW engineer also has questions regarding the unused OSPI pins. We have them as NC (not connected) now on our schematic. Since we need to configure them in SBL, should we add week pull down on those un-used spare pins?

Thanks, 
Hong 

Hello Hong,

Hong Zhang said:

Could TI help me to understand why the spare OSPI pins are required to be configured for the primary UART boot mode case, but not for the backup UART boot mode case? 

It is written in the TRM that in case when you boot with OSPI as primary boot mode(UART as backup boot mode) then all the pins are configured despite them being in use. Please find the relevant snapshot below. Also read the NOTE mentioned in the snapshot at the bottom.

Hong Zhang said:

In addition, I would like to further discuss the QSPI pin reset suggestion as you posted before. For our latest schematic, we do have this pin connected in our design, but not in our previous design. I would like to understand TI's suggestion about this QSPI pin reset. 

I will explain about where this is actually used in the SDK and for what purpose in the call tomorrow.

Regards,

Vaibhav

Hong

Please also point the follow FAQ to your hardware team

Specifically 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1307344/faq-am625-am623-am62a-am62p-design-recommendations-commonly-observed-errors-during-custom-board-hardware-design-ospi-qspi-memory-interface

Regards

Mukul 

Hello Hong,

Additionally following up on what we discussed in the meeting.

The SPI primary bootmode which you were using requires D0 and D1 and the rest of the D2....Dn lines can be ignored.

You confirmed the working of it as well with just D0 and D1 lines configured along with the clock and chip select line.

So we have a good progress here.

Apart from this I was to explain the use of the reset line which should be connected from the SoC to the flash part.

This will help you to reset the flash part with the help of the API named as: 

Hello Vaibhav, 

Thanks for following up with this thread.  

I did further testing that showed the configuration of D0 and D1 can program the bootable image into bootflash at primary UART boot mode. I think we have been leveraging the bootROM in SPI mode to configure the OSPI interface, and didn't see this bug until moving to primary UART boot mode case. 

This further leads to the topic about resetting flash part to put the part into a clean state when booting into FW or booting from ROM. 

I have been discussing with our HW engineer regarding the feasibility of adding flashFixUpQspiBoot in our FW.
We noticed:
1) The flash part we used doesn't have a dedicated QSPI flash reset pin. This pin is QSPI DO3 when it is in QSPI mode, and it is the shared pin as HOLD# when it operates in SPI mode. 
2) We would like to seek the design review feedback for this specific issue, since we could not directly follow TI EVM's schematic. I will follow up with email about this.  

Hello Hong,

Hong Zhang said:

and didn't see this bug until moving to primary UART boot mode case. 

This is not a bug necessarily, its just an interpretation error, SPI using D0 and D1 is common in my opinion. But glad that its working at your end now.

Hong Zhang said:

1) The flash part we used doesn't have a dedicated QSPI flash reset pin. This pin is QSPI DO3 when it is in QSPI mode, and it is the shared pin as HOLD# when it operates in SPI mode. 
2) We would like to seek the design review feedback for this specific issue, since we could not directly follow TI EVM's schematic. I will follow up with email about this.  

We will be looking forward to the mail.

Regards,

Vaibhav

Hello Vaibhav, 

Sorry, I didn't make it clear. This is a bug in our codebase from previous development. It works fine in SPI boot mode, because ROM helps to initialize the SPI interface.  When moving to primary UART boot mode, this becomes an issue because our code base didn't configure D1 pin that is necessary for 1s-1s-1s mode. 

I saw there is a separate thread about schematic review, and I will add you to that thread. 

Thanks, 
Hong 

Hello Hong,

Thanks for your response.

Hong Zhang said:

Sorry, I didn't make it clear. This is a bug in our codebase from previous development

Okay now I understood it.

Hong Zhang said:

I saw there is a separate thread about schematic review, and I will add you to that thread. 

Sure, can you also go ahead and add Kallikuppa Sreenivasa to the thread?

Regards,

Vaibhav

Hello Vaibhav,

Could you please check your email, I already added you to the thread.

 I will talk to John today to see whether he can add Kallikuppa in the thread (I don't think I have his email) or you feel free to add him. 

Hong 

Hello Hong,

Yes I will check the mail,

Regards,

Vaibhav