Other Parts Discussed in Thread: AM2431, , SYSCONFIG, UNIFLASH
Hi all TI experts,
I am currently developing on the AM2431 platform, using the W25Q16JV as the external flash model. The SDK version I'm using is mcu_plus_sdk_am243x_09_00_00_35.
I replaced the external flash on the LP-AM243 with the W25Q16JV, which is the flash our product uses. Following the methods provided in the document at
I executed the procedure and obtained the following results:
{
"flashSize": 2097152,
"flashPageSize": 256,
"flashManfId": "0xEF",
"flashDeviceId": "0x4015",
"flashBlockSize": 65536,
"flashSectorSize": 4096,
"cmdBlockErase3B": "0xD8",
"cmdBlockErase4B": "0xD8",
"cmdSectorErase3B": "0x20",
"cmdSectorErase4B": "0x20",
"protos": {
"p111": {
"isDtr": false,
"cmdRd": "0x03",
"cmdWr": "0x02",
"modeClksCmd": 0,
"modeClksRd": 0,
"dummyClksCmd": 0,
"dummyClksRd": 0,
"enableType": "0",
"enableSeq": "0x00",
"dummyCfg": null,
"protoCfg": null,
"strDtrCfg": null
},
"p112": {
"isDtr": false,
"cmdRd": "0x3B",
"cmdWr": "0x02",
"modeClksCmd": 0,
"modeClksRd": 0,
"dummyClksCmd": 0,
"dummyClksRd": 8,
"enableType": "0",
"enableSeq": "0x00",
"dummyCfg": null,
"protoCfg": null,
"strDtrCfg": null
},
"p114": {
"isDtr": false,
"cmdRd": "0x6B",
"cmdWr": "0x02",
"modeClksCmd": 0,
"modeClksRd": 0,
"dummyClksCmd": 0,
"dummyClksRd": 8,
"enableType": "4",
"enableSeq": "0x00",
"dummyCfg": null,
"protoCfg": null,
"strDtrCfg": null
},
"p118": null,
"p444s": {
"isDtr": false,
"cmdRd": "0xEB",
"cmdWr": "0x02",
"modeClksCmd": 0,
"modeClksRd": 2,
"dummyClksCmd": 0,
"dummyClksRd": 0,
"enableType": "4",
"enableSeq": "0x11",
"dummyCfg": {
"isAddrReg": false,
"cmdRegRd":"0x00",
"cmdRegWr":"0x00",
"cfgReg":"0x00000000",
"shift":0,
"mask":"0x00",
"bitP":0
},
"protoCfg": {
"isAddrReg": false,
"cmdRegRd": "0x00",
"cmdRegWr": "0x00",
"cfgReg": "0x00000000",
"shift": 0,
"mask": "0x00",
"bitP": 0
},
"strDtrCfg": {
"isAddrReg": false,
"cmdRegRd": "0x00",
"cmdRegWr": "0x00",
"cfgReg": "0x00000000",
"shift": 0,
"mask": "0x00",
"bitP": 0
}
},
"p444d": {
"isDtr": false,
"cmdRd": "0xEB",
"cmdWr": "0x02",
"modeClksCmd": 0,
"modeClksRd": 2,
"dummyClksCmd": 0,
"dummyClksRd": 0,
"enableType": "4",
"enableSeq": "0x11",
"dummyCfg": {
"isAddrReg": false,
"cmdRegRd":"0x00",
"cmdRegWr":"0x00",
"cfgReg":"0x00000000",
"shift":0,
"mask":"0x00",
"bitP":0
},
"protoCfg": {
"isAddrReg": false,
"cmdRegRd": "0x00",
"cmdRegWr": "0x00",
"cfgReg": "0x00000000",
"shift": 0,
"mask": "0x00",
"bitP": 0
},
"strDtrCfg": {
"isAddrReg": false,
"cmdRegRd": "0x00",
"cmdRegWr": "0x00",
"cfgReg": "0x00000000",
"shift": 0,
"mask": "0x00",
"bitP": 0
}
},
"p888s": null,
"p888d": null,
"pCustom": {
"fxn": null
}
},
"addrByteSupport": "0",
"fourByteAddrEnSeq": "0x80",
"cmdExtType": "NONE",
"resetType": "0x30",
"deviceBusyType": "1",
"cmdWren": "0x06",
"cmdRdsr": "0x05",
"srWip": 0,
"srWel": 1,
"cmdChipErase": "0xC7",
"rdIdSettings": {
"cmd": "0x9F",
"numBytes": 5,
"dummy4": 0,
"dummy8": 0
},
"xspiWipRdCmd": "0x00",
"xspiWipReg": "0x00000000",
"xspiWipBit": 0,
"flashDeviceBusyTimeout": 5120000,
"flashPageProgTimeout": 704
}
Since I am using uart_unflash
to program the SBL and application into the AM243, I need to modify the flash-related parts in both SBL and SBL_UART_unflash
. My SBL is SBL_OSPI
. Following the document's guidance, I imported the JSON file into the sysconfig of both SBL_UART_uniflash
and SBL_OSPI
. Here are the issues I encountered:
In the first scenario, both SBL_UART_uniflash
and SBL_OSPI
are set to 1s-1s-1s configurations. When I attempt to flash the firmware to the LP-AM243 using uart_flash.py
, the first command successfully writes SBL_UART_uniflash
to RAM without any issues. However, the second command, which is intended to flash SBL_OSPI
, should initiate SBL_UART_uniflash
to start receiving SBL_OSPI
. Yet, the process consistently freezes at this point without any progression. From my assessment, it appears that SBL_UART_uniflash
encounters an issue at this stage, possibly getting stuck and unable to proceed with the flashing operation.
In the second scenario, SBL_UART_uniflash
is configured as 4s-4s-4s and SBL_OSPI
as 1s-1s-1s. The flashing process using uart_flash.py
completes without any issues, and all three commands are successfully executed, resulting in both the SBL and application being correctly programmed. However, upon booting in OSPI mode, a log message appears stating, "Some tests have failed!!". Further investigation reveals that the issue originates from the Bootloader_parseMultiCoreAppImage
function, which returns a status of false.
In the third scenario, both SBL_UART_uniflash
and SBL_OSPI
are configured as 4s-4s-4s. The flashing process completes without any issues, and the system successfully boots from OSPI mode into the application. However, there is a problem where the application is unable to perform a software reset. This issue was discussed in another thread, which can be found at the following link:
The conclusion from that discussion is that when testing the application alone, setting the application's flash configuration to 1s-1s-1s allows the software reset to function properly. Thus, it is inferred that the SBL might be facing a similar issue, indicating a need to test with all flash configurations set to 1s-1s-1s.
Did I do anything wrong? I also referred to the [FAQ] written by another TI expert on "How to debug/develop/migrate the flash driver for custom flash on non-TI EVM" available at: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1230063/faq-mcu-plus-sdk-am243x-faq-how-to-debug-develop-migrate-the-flash-driver-for-custom-flash-on-non-ti-evm-ospi-xspi
However, I still can't identify the problem. Is there something wrong with my approach?
As an aside, I did manage to damage this flash during testing. The situation was that the UART flashing process completed successfully, but when booting in OSPI mode, no logs appeared. Debug mode revealed that the address was consistently at 0x418019F0. According to TI experts in another discussion thread, this is a ROM address. I suspect it's stuck in the RBL, possibly because the RBL is unable to gain control of the external flash, thus causing it to hang. This situation is identical to what I observed when testing the software reset. I wonder if there is some connection between these issues.
Best,
Larry