AM2434: Issue with OSPI Boot Mode on AM2434_ALV Controller After Successful Flash Integration

Hello,

Could you please let me know the following:

• The custom flash part you are using?
• The exact bootmode pins you used for OSPI bootmode?

Thanks!

Hello,

Thank you for reaching out.

1. The custom flash part we are using is MT25QL01GBBB.
2. The boot mode pins we used for OSPI boot mode are:
   • BOOTMODE [0:7] (SW2) = 1100 1110
   • BOOTMODE [8:15] (SW3) = 0100 0000

Additionally, since I don’t have a UART port, my only option for flashing is OSPI JTAG UniFlash.

Hello,

Thanks for the info!!

Could you help me the following doubts?

1) I assume the flash supports 8d-8d-8d mode & you obtained the flash configurations using the OSPI_FLASH_DIAG example. The obtained flash configurations were then used in SBL_JTAG_UNIFLASH, OSPI_FLASH_DMA, & OSPI_FLASH_IO examples so that they are compatible with the custom flash part?

2) How do you intend to verify if the device is booting if you don't have UART port?

3)  

Divyesh Patel said:

my code does not boot and automatically falls back to the secondary bootloader.

Can you please elaborate more on this? How do you know it is falling back to secondary bootloader & where this bootloader resides?

Thanks!

Hello,

Thank you for your follow-up questions. Please see my responses below:

1. Flash mode and configurations:
   No, the flash does not support 8d-8d-8d mode. I am running the flash in 1S-1S-1S mode, and it works perfectly in this mode. The examples like SBL_JTAG_UNIFLASH, OSPI_FLASH_DMA, and OSPI_FLASH_IO all function correctly based on the 1S-1S-1S mode configuration.

2. Verifying the boot without UART:
   Since I don’t have a UART port, I use an LED blinking code to verify if the device has successfully booted. However, the LED blink code doesn’t execute, indicating that the boot process isn’t completing.
3. Fallback to secondary bootloader:
   The device falls back to the backup boot mode because the primary boot mode, which is xSPI boot, fails to execute the code.

Best regards,

Divyesh Patel

Divyesh Patel said:

No, the flash does not support 8d-8d-8d mode.

Since, the flash doesn't support or not verifed to work in this mode, please try the following bootmode pins configuration

• BOOTMODE [0:7] (SW2) = 1100 1110
• BOOTMODE [8:15] (SW3) = 0000 0000

As described in the TRM, if the BIT9 is set, the ROM reads the SFDP table & tries to read the image from flash in 8d mode.

Let me know if this works...

Hello,

Thank you for your suggestion.

I tried the following boot mode pin configuration as you recommended:

• BOOTMODE [0:7] (SW2) = 1100 1110
• BOOTMODE [8:15] (SW3) = 0000 0000

However, the firmware still didn’t boot with this setup. Since the flash doesn’t support 8d mode, it seems the ROM’s attempt to read the SFDP table and boot in this mode isn’t compatible with my flash.

Please let me know if there are any other steps I should try.

Best regards,

Divyesh Patel

Hi, can you also try the following SPI bootmode

• BOOTMODE [0:7] (SW2) = 1101 1000
• BOOTMODE [8:15] (SW3) = 0000 0000

Apart from this, what is the backup boot you are using which is letting you know that the ROM is not able to boot from primary boot media & so jumping to backup boot?

Hello,

Thank you for the suggestion.

I tried the following SPI boot mode configuration:

• BOOTMODE [0:7] (SW2) = 1101 1000
• BOOTMODE [8:15] (SW3) = 0000 0000

Unfortunately, the firmware still didn’t boot with this setup. I also attempted OSPI and QSPI boot modes previously, but neither worked.

As for the backup boot mode, my backup boot mode is currently set to null, so there is no actual secondary bootloader in place. Since the ROM is unable to boot from the primary boot media (xSPI), it defaults to the backup boot, but nothing gets executed due to the null configuration.

Please let me know if there’s anything else I should try.

Best regards,

Divyesh Patel

Hello,

Divyesh Patel said:

As for the backup boot mode, my backup boot mode is currently set to null, so there is no actual secondary bootloader in place.

Then, you can not say for sure if the ROM is failing to boot the SBL from primary bootmedia. Maybe the SBL is booting but not able to boot your led blink application.

Can you again try the different bootmodes we discussed above? For each one, please connect the debugger to the R5FSS0-0 core & see the address at which the core is suspended at. If it's something 0x41xxxxxx then the execution is in ROM meaning it fails to boot the SBL. If it's 700xxxxx then SBL is at least booting.

Regards,

Prashant

Hello,

I retried both the OSPI boot mode and SPI boot mode as discussed. When I connected the debugger to the R5FSS0-0 core, the address where the core was suspended showed 0x41xxxxxx, indicating that the execution is stuck in ROM and that the SBL is failing to boot.

Please let me know the next steps or if there’s anything else I should investigate.

Best regards,

Divyesh Patel

Hi, that confirms the ROM is not able to boot the SBL. It may be because the SBL is not flashed correctly or the ROM is really having trouble communicating with your custom flash part.

Divyesh Patel said:

For flashing the code onto the controller, I used sbl_jtag_uniflash_am243x-evm_r5fss0-0_nortos_ti-arm-clang, and it worked perfectly.

Can you once share the flashing logs from this procedure? Basically, I would like to have a look at the different images you are flashing & their offsets.

Thanks!

Hello,

here are the flashing logs from the procedure:

[MAIN_Cortex_R5_0_0]  
 
 ==================
 JTAG Uniflash Menu
 ==================
 
 1: Erase Complete Flash
 2: Write File to Flash and Verify
 3: Verify file in Flash
 
 x: Exit
 
 Enter Choice: 2

 Enter file name along with path to write or verify : C:/Users/Admin/workspace_ipc/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage
 Enter flash offset (in hex format) : 0x0
 Enter below command in CCS scripting console to load the file data to memory.
 AFTER the file load is done, enter '1' to continue ...

 loadRaw(0x80000020, 0, "C:/Users/Admin/workspace_ipc/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage", 32, false);
1
 [FLASH WRITER] Flashing success!!...
 
 
 ==================
 JTAG Uniflash Menu
 ==================
 
 1: Erase Complete Flash
 2: Write File to Flash and Verify
 3: Verify file in Flash
 
 x: Exit
 
 Enter Choice: 3

 Enter file name along with path to write or verify : C:/Users/Admin/workspace_ipc/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage
 Enter flash offset (in hex format) : 0x0
 Enter below command in CCS scripting console to load the file data to memory.
 AFTER the file load is done, enter '1' to continue ...

 loadRaw(0x80000020, 0, "C:/Users/Admin/workspace_ipc/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage", 32, false);
1
 [FLASH WRITER] Verifying success!!...
 
 
 ==================
 JTAG Uniflash Menu
 ==================
 
 1: Erase Complete Flash
 2: Write File to Flash and Verify
 3: Verify file in Flash
 
 x: Exit
 
 Enter Choice: 2

 Enter file name along with path to write or verify : C:/Users/Admin/workspace_ipc/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage
 Enter flash offset (in hex format) : 0x80000
 Enter below command in CCS scripting console to load the file data to memory.
 AFTER the file load is done, enter '1' to continue ...

 loadRaw(0x80000020, 0, "C:/Users/Admin/workspace_ipc/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage", 32, false);
1
 [FLASH WRITER] Flashing success!!...
 
 
 ==================
 JTAG Uniflash Menu
 ==================
 
 1: Erase Complete Flash
 2: Write File to Flash and Verify
 3: Verify file in Flash
 
 x: Exit
 
 Enter Choice: 3

 Enter file name along with path to write or verify : C:/Users/Admin/workspace_ipc/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage
 Enter flash offset (in hex format) : 0x80000
 Enter below command in CCS scripting console to load the file data to memory.
 AFTER the file load is done, enter '1' to continue ...

 loadRaw(0x80000020, 0, "C:/Users/Admin/workspace_ipc/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang/Debug/gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage", 32, false);
1
 [FLASH WRITER] Verifying success!!...
 
 
 ==================
 JTAG Uniflash Menu
 ==================
 
 1: Erase Complete Flash
 2: Write File to Flash and Verify
 3: Verify file in Flash
 
 x: Exit
 
 Enter Choice: x

 [FLASH WRITER] Application exited !!!
All tests have passed!!

The images I flashed and their offsets are:

• sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage at 0x0
• gpio_led_blink_am243x-evm_r5fss0-0_nortos_ti-arm-clang.appimage at 0x80000

Please let me know if you need any more details.

Best regards,

Divyesh Patel

Divyesh Patel said:

sbl_ospi_am243x-evm_r5fss0-0_nortos_ti-arm-clang.tiimage at 0x0

You are flashing the GP image. Are you working with the GP device? If so, what is the SDK version you are using? The SDK does not have the support for GP devices since the first SDK v9.

Regards,

Prashant

Hello Prashant,

I am working with the AM2434_ALV controller, and I am currently using the mcu_plus_sdk_am243x_08_03_00_18 SDK.

Best regards,

Divyesh Patel

Can you once read the register 0x44234100 to determine the device type?

In any case, may I know the reason for using this much old SDK version? Even if this issue gets resolved, we may not be able to spend time on the issues, if any, in the future with this SDK version.

I read the register 0x44234100, and the value returned is 0x00000003.

The reason we are using this older SDK version (mcu_plus_sdk_am243x_08_03_00_18) is that our development is already completed with it. The only remaining task is to successfully flash the code to the flash memory.

Hello,

Thanks for the clarification!

So, the device is definitely GP, you are flashing the right image types, & the flashing procedure looks good. I think it's time to confirm the actual content of the flash at offset 0x0.

Can you load any OSPI example preferably OSPI_FLASH_IO & stop the execution just after the Board_driversOpen call?

Assuming the flash will be in DAC at this point, please check the memory at 0x60000000 using Memory Browser view. Do you see the bytes matching with the hex dump of the flashed SBL image?

Regards,

Prashant

Hello Prashant,

I followed your suggestion and loaded the OSPI_FLASH_IO example, stopping the execution right after the Board_driversOpen call. However, when I checked the memory at 0x60000000 using the Memory Browser, I didn’t see any content. The memory seems empty, and no bytes are matching the hex dump of the flashed SBL image.

Please let me know your thoughts on this or if there’s anything else I should try.

Best regards,

Divyesh Patel

Divyesh Patel said:

The memory seems empty,

It looks like the DAC is not enabled. Can you check after the first R/W test? The "Flash_read" should leave the flash in DAC state. You may let the R/W happen since it does not conflict with the address 0x0.

If you still do not see any content, you may enable DAC manually with the following patch

diff --git a/examples/drivers/ospi/ospi_flash_io/ospi_flash_io.c b/examples/drivers/ospi/ospi_flash_io/ospi_flash_io.c
index 4a5fe56cebd..3eda4f4f58d 100644
--- a/examples/drivers/ospi/ospi_flash_io/ospi_flash_io.c
+++ b/examples/drivers/ospi/ospi_flash_io/ospi_flash_io.c
@@ -57,6 +57,9 @@ void ospi_flash_io_main(void *args)
     status = Board_driversOpen();
     DebugP_assert(status==SystemP_SUCCESS);
 
+    OSPI_Handle handle = OSPI_getHandle(CONFIG_OSPI0);
+    OSPI_enableDacMode(handle);
+
     flashAttrs = Flash_getAttrs(CONFIG_FLASH0);
 
     /* Fill buffers with known data,

Hello,

I ran the R/W test as suggested, and the memory at 0x60000000 is now showing hex values.

I also tried manually enabling DAC, and it displayed the same hex values as after the R/W test.

Please let me know if this confirms that DAC mode is functioning properly or if there are any further steps to take.

Best regards,

Divyesh Patel

Hello,

Yes the flash is in DAC mode. The SBL image seems to be flashed. Can you compare few initial bytes with the hex dump of your actual SBL image just to be sure the image is flashed correctly.

If you think the image is flashed correctly, can you checkout the Section 1 of this FAQ & see if anything stands out that may explain the issue?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1358039/faq-board-bring-up-tips-for-sitara-devices-am64x-am243x-am62x-am62ax-am62px

Regards,

Prashant

Hello Prashant,

I compared the initial bytes with the hex dump of the actual SBL image, and they match correctly, so it seems the image is flashed properly.

Regarding the power state, after the initial power sequence, both MCU_RESETSTAT and RESETSTAT go high. We have verified the boot pins for SPI, and they are configured correctly. The boot mode voltage level signals are at 0-3.3V.

Since we are booting from SPI, the OSPI0_CLK toggles at 6MHz, and when the clock is present, the OSPI0_CSN0 pin goes low. You can see the signals in the attached image.

We also tried performing a warm reset after powering up the board, but it didn't resolve the issue.

Best regards,

Divyesh Patel

Hi,

Divyesh Patel said:

Since we are booting from SPI, the OSPI0_CLK toggles at 6MHz, and when the clock is present, the OSPI0_CSN0 pin goes low.

It looks like the ROM is trying to talk to the flash. Do you see any activity on the data lines?

Apart from this, does your board schematic adheres to the following requirement mentioned in the TRM chapter 4.4.1 OSPI, xSPI, QSPI, SPI Boot

Regards,

Prashant

hello,

Yes, I do see activity on the DQ0 pin.

In our board, the flash reset pin is connected to the DQ3 pin. From the hardware side, it's not possible to directly reset the flash.

Could you suggest how we can perform a flash reset in this scenario? Any software-based workaround would be helpful.

Best regards,

Divyesh Patel

Hi, please checkout the following snippet

/* File: source/drivers/ospi/v0/ospi_nor_flash.c */

int32_t OSPI_norFlashInit1s1s1s(OSPI_Handle handle)
{
    ...
    /* Reset the Flash */
    cmd = OSPI_NOR_CMD_RSTEN;
    OSPI_norFlashCmdWrite(handle, cmd, 0xFFFFFFFF, NULL, 0);

    cmd = OSPI_NOR_CMD_RST;
    OSPI_norFlashCmdWrite(handle, cmd, 0xFFFFFFFF, NULL, 0);
    ...
}

I am not a hardware expert but there should be a provision of completely shutting down the flash with Cold POR via PMIC. Isn't it the case with your board?

Hello,

We do have a button for completely shutting down the flash via Cold POR using the PMIC, but unfortunately, it still doesn't resolve the issue.

Best regards,

Divyesh Patel

Divyesh, how did you confirm your code flashes the LED?  Did you load it by some other means and test it on the board?

Earlier in the thread you mentioned the code never gets out of 0x41xxxxxx area of memory.  Is this still the case?  Does it ever execute in the area of 0x700xxxxx?  Can you confirm if the full SBL image gets downloaded to internal memory?

Regards,

James

Hi James,

I confirmed my code flashes the LED by running the SoC initialization script and loading it onto the EVM board, where it works as expected. However, using the same procedure on my custom board, it doesn't work.

In SPI boot mode on my custom board, the code remains in the 0x41xxxxxx memory area and never executes in the 0x700xxxxx region where the application should run. I verified this by checking address 0x6080000 and using the OSPI_jtag_uniflash example to confirm the image is correctly programmed into flash memory.

If there is any other method to verify this, please let me know.

Best regards,

Divyesh

Hi Divyesh,

before trying to debug your boot issues, i think you need to understand why the code doesn't work on your custom board.  Are you running the SoC initialization script on your custom board, and then loading the LED blink code and running it?  Is the code hanging somewhere?  Why doesn't it blink your LED?  Can you dig further into this, otherwise your criteria for checking boot code isn't valid

Regards,

James

Hello James,

Apologies for the miscommunication. In Dev Boot mode, after running the SoC initialization script on my custom board, the LED blink code works perfectly.

However, after using the "sbl_jtag_uniflash_am243x-evm_r5fss0-0_nortos_ti-arm-clang" example to upload the code onto my custom board, the upload is successful. But once I change the boot mode to SPI boot, the code does not boot.

Best regards,
Divyesh

Hello,

Yes, the code now executes in the 0x700xxxxx memory area, but the LED blink code still doesn't work.

For debugging the SBL boot, I followed the steps outlined in this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1294675/faq-am62x-am64x-faq-debugging-sbl-boot-in-rtos-sdk , it confirmed that the image is downloaded to internal memory by checking the 0x6080000 and 0x6000000 memory addresses.

For booting, I'm using B0-B7: 11001110, B8-B15: 00000000 in XSPI bootmode.

Best regards,
Divyesh

Before proceeding further, may I know what is changed now that the xSPI boot with 1S is now working? I did mention to try this out previously to which you reported it is also not working.

Thanks!

Hello,

I reinstalled the SDK, created a new flash file, and made some modifications to the flash library code, specifically adding a routine to restart the flash. These changes seem to have resolved the issue, and now the xSPI boot with 1S is working as expected.

Best regards,
Divyesh

Hello,

That sounds good.

But, if you are doing a PMIC reset, the SBL or application's code really does not matter since the board will be powered on from scratch. The ROM should get the flash in the clean state. Maybe your board's schematics has a different story.

Divyesh Patel said:

For debugging the SBL boot, I followed the steps outlined in this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1294675/faq-am62x-am64x-faq-debugging-sbl-boot-in-rtos-sdk ,

Coming to this, may I know what exact steps you are doing? Have you tried loading the SBL's symbols to see where the execution is stuck?

Regards,

Prashant