AM6442: Problems with OSPI Flash on custom board

Dominik Fischer

Part Number: AM6442
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi TI-Team,

some time ago we built a custom board with AM243x chip (Board A). We did a new revision of this board with a AM6442 chip (Board B).

On board B we now have problems to get OSPI boot running. On the new boards the exact same flash was used, which was successfully tested/used on the Board A in conjuction with AM243x. The assembled flash is a Micron MT35XU512ABA1G12-0AAT.
The OSPI flash in general is working. This means after booting in DEV-Boot mode and doing basic SOC init I can successfully execute programs using OSPI Flash such as OSPI Flash IO or OSPI Flash Diagnostic. I am also able to flash a bootloader via a modified JTAG uniflash program.

Here is the read JEDEC information:

{

	"flashSize": 67108864,
	"flashPageSize": 256,
	"flashManfId": "0x2C",
	"flashDeviceId": "0x5B1A",
	"flashBlockSize": 131072,
	"flashSectorSize": 4096,
	"cmdBlockErase3B": "0xD8",
	"cmdBlockErase4B": "0xDC",
	"cmdSectorErase3B": "0x20",
	"cmdSectorErase4B": "0x21",
	"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": null,
		"p114": null,
		"p118": {
			"isDtr": false,
			"cmdRd": "0x7C",
			"cmdWr": "0x84",
			"modeClksCmd": 0,
			"modeClksRd": 1,
			"dummyClksCmd": 0,
			"dummyClksRd": 7,
			"enableType": "0",
			"enableSeq": "0x00",
			"dummyCfg": null,
			"protoCfg": null,
			"strDtrCfg": null
		},
		"p444s": null,
		"p444d": null,
		"p888s": null,
		"p888d": {
			"isDtr": false,
			"cmdRd": "0x0B",
			"cmdWr": "0x12",
			"modeClksCmd": 0,
			"modeClksRd": 0,
			"dummyClksCmd": 8,
			"dummyClksRd": 20,
			"enableType": "0",
			"enableSeq": "0x00",
			"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
			}
		},
		"pCustom": { 
			"fxn": null
		}
	},
	"addrByteSupport": "1",
	"fourByteAddrEnSeq": "0xA1",
	"cmdExtType": "REPEAT",
	"resetType": "0x10",
	"deviceBusyType": "0",
	"cmdWren": "0x06",
	"cmdRdsr": "0x05",
	"srWip":  0,
	"srWel":  0,
	"cmdChipErase": "0xC7",
	"rdIdSettings": {
		"cmd": "0x9F",
		"numBytes": 5,
		"dummy4": 0,
		"dummy8": 0
	},
	"xspiWipRdCmd": "0x00",
	"xspiWipReg": "0x00000000",
	"xspiWipBit": 0,
	"flashDeviceBusyTimeout": 64000000,
	"flashPageProgTimeout": 120
}

However, after booting I will not enter the SBL NULL bootloader and cannot see any messages print on debug UART.
I tried to debug SBL NULL by adding a `loop_forever()` directly in main. However, I will not be able to step into loop. Instead I see that I am stuck at "strange" addresses.

So for me it seems like ROM-code of chip is not able to successfully access OSPI Flash at boot time.
Do I have any further debugging possibilities?
Are there any registers etc. where I could find out what the problem is?

Thanks for any help or tips in advance!

Kind regards,
Dominik

8 months ago

0 Meet Thakar 7 months ago

TI__Genius 14145 points

Hi Dominik,

This is not any issue with the flash, I think this is because of the warm reset workaround implemented in the SBL_NULL:

Just for the testing purpose, you can define this macro DISABLE_WARM_REST_WA in your sbl_null to disable this warm reset workaround. Then rebuild and re-flash the SBL to check if you are able to move forward with your debugging.

Best Regards,

Meet.

0 Dominik Fischer 7 months ago in reply to Meet Thakar

Intellectual 480 points

Hi Meet,

first of all thanks for your response. However, I think the problem is not connected with the warm reset. As my loop_forever() is already called before the warmreset would be done. Nevertheless, I defined the macro and tried again. I had the same behavior and stop at a similar address.

0 Dominik Fischer 7 months ago in reply to Dominik Fischer

Intellectual 480 points

In the meantime we made some progress but we need some further assistance:
- We found out that the flash assembled on the newer boards delivers more data in the SFDP table
- In the old versions no config for 8D-8D-8D was delivered
- If we assemble an old flash on the board we are able to flash a bootloader and see the bootloader output

Therefore, we think that the following entry of errata is the same problem we have:
i2366: Boot: ROM does not comprehend specific JEDEC SFDP features for 8D-8D-8D operation
www.ti.com/.../sprz457i.pdf

There is a workaround described: "the memory must be programmed with a swapped byte order from the factory or programmed with the SoC"

What does this mean exactly? We programmed via JTAG uniflash but still have the problems, so what is meant by programmed with the SoC? How can we swap byte order and how do we need to swap (is it 4 Bytes or 2 Bytes we swap)?

0 Dominik Fischer 7 months ago in reply to Dominik Fischer

Intellectual 480 points

Update: I tried to swap the bytes of the sbl_null bootloader in 4-Byte and 2-Byte "format" but both versions are not booting successfully. Can you please clarify what is meant with "the memory must be programmed with a swapped byte order"?

+1 Dominik Fischer 7 months ago in reply to Dominik Fischer

Intellectual 480 points

We solved the issue by setting Bit 9 in bootmode to 0 and therefore preventing reading SFDP table. We are now able to boot SBL_NULL:

Processors

Processors forum

AM6442: Problems with OSPI Flash on custom board