AM263P4-Q1: SOC Does Not Reboot After PORz

Hi Kier,

Thank you for the query!!

Can you please help me with the following details:

1. Is the nCS, IO2, nRESET line pulled high with a weak pull up?
2. Is the nRST connected to PORz release circuitry?
3. Which version of SDK are you using?
4. Are you setting the Flash in 3-byte addressing mode or in 4-byte addressing mode?
   
   Can you please share the schematic snippet of PORz release logic?

Thanks & Regards,
Rijohn

Hi Rijohn,

Thanks for the quick reply.

Rijohn Pius said:

Is the nCS, IO2, nRESET line pulled high with a weak pull up?

No, there are no external pullup resistors on these lines.

Rijohn Pius said:

Is the nRST connected to PORz release circuitry?

No. We're not using the HW reset since the boot mode is QUAD.

Rijohn Pius said:

Which version of SDK are you using?

SDK 10.2.0.15

Rijohn Pius said:

Are you setting the Flash in 3-byte addressing mode or in 4-byte addressing mode?

In the FLASH configuration 4-byte is selected:

But I checked this through debug and it's hitting the following line which looks like it's setting 3-byte.

Note also in the screenshot above the code always assumes a OSPI_RESETPIN_DEDICATED. There's no way to select the other option: OSPI_RESETPIN_DQ3 which would be more appropriate for our device, even though we aren't using it because we use QUAD mode. Just an observation.

Hi Keir,

Thank you for the quick response!!

Kier said:

No, there are no external pullup resistors on these lines.

It is recommended to have an external pull up on these lines. As MCU ROM does not enable the internal pull up on these lines by default.

Kier said:

In the FLASH configuration 4-byte is selected:

Disable the 4-byte addressing mode in SysConfig. Below is the reason:


Let's keep the addressing mode fixed to 3-byte as our flash size is not greater than 128Mb 

Kier said:

There's no way to select the other option: OSPI_RESETPIN_DQ3 which would be more appropriate for our device, even though we aren't using it because we use QUAD mode.

Good Catch!! We need not have it in this case as there is no dedicated reset line. Comment OSPI_configResetPin API. Please comment it, save and rebuild the project.

Thanks & Regards,
Rijohn

Thank you.

We'll have to park the pullup concern for the moment because I can't change that right now. Anyway, I'm not convinced this is the cause because the system works on power-on. If the pull-ups are correct at power on surely they are correct at PORz?

In any case, I checked that a reset is issued when the flash driver closes after use.

This should mean that as long as Flash_close() is called before the PORz, the flash IC should be in the same condition as a power-up shouldn't it?

BTW, I tried changing to 3 byte addressing but now my application can't write to flash and doesn't fix the issue anyway.

However, there's no getting away from the fact that with a cold power on the RBL can read from the flash chip. If the RBL only supports 3 byte addressing then we can conclude the flash is successfully supporting both 3 and 4 byte addressing. This can't be the cause.

I can only conclude that the Flash_norOspiReset() is not successful in returning the device to its power-on state.

Hi Kier,

Can you please share here the example.sysconfig file of the SBL project.

Yes, we might need to tweak the Flash_norOspiReset() for the case of this particular. I will check on this and get back to you.

Kier said:

there's no getting away from the fact that with a cold power on the RBL can read from the flash chip. If the RBL only supports 3 byte addressing then we can conclude the flash is successfully supporting both 3 and 4 byte addressing.

Hi Rijohn,

Rijohn Pius said:

Can you please share here the example.sysconfig file of the SBL project.

Here's my syscfg file for the core0. I stripped out everything except OSPI and FLASH to protect IP. Let me know if some aspect is missing that you need.

1667.Project.zip

Rijohn Pius said:

if the SBL or application switches the flash to 4-byte addressing mode and a reset is triggered, the flash will remain stuck in 4-byte mode

Why do you think it gets stuck in 4 byte addressing mode after a reset?

The device has a non-volatile setting for address mode:

Since RBL is able to talk to the flash after power on, we can conclude this must = 0, right? I will check its state after the reset command has been issued.

I added some code to read the contents of the CR2V register before and after reset.

BEFORE Reset : Bit 0 is set indicating 4 byte addressing.

AFTER Reset : Bit 0 is reset (default) indicating 3 byte addressing.

So at the point of PORz from PMIC, the flash IC is in 3 byte address mode. I think evidence is mounting that this cannot be the cause for a lack of reboot.

Hi Kier,

Can you please run the ospi_flash_diag example and share the console output?

Kier said:

BEFORE Reset : Bit 0 is set indicating 4 byte addressing.

Can you please disable the 4-byte addressing mode in sysconfig.

Thanks & Regards,
Rijohn

Hi Rijohn,

Thank you I will try this but why do you think this will make a difference in theory? I have demonstrated that the device is in 3 byte address before a PORz.

What if I had a device greater than 128Mb and I had no option but to use 4 byte addressing? Your answer suggests that it's impossible to use such a device with this SOC. Is that correct?

Hi Kier,

Kier said:

BEFORE Reset : Bit 0 is set indicating 4 byte addressing.

I see from your previous answer that BEFORE RESET flash is in 4-byte addressing mode. Sorry I am confused here.

I have tested AM263Px + S25FL128 series of flash setting in 3-byte addressing mode. Please try updating the commands as mentioned in previous thread and let me know.

Kier said:

What if I had a device greater than 128Mb and I had no option but to use 4 byte addressing? Your answer suggests that it's impossible to use such a device with this SOC. Is that correct?

Yes, Current AM263Px ROM does not support flashes with only 4-byte addressing mode.


Thanks, 
Rijohn

Hi Rijohn,

Rijohn Pius said:

Please try updating the commands as mentioned in previous thread and let me know.

Yes, I will try it, thank you.

Rijohn Pius said:

Yes, Current AM263Px ROM does not support flashes with only 4-byte addressing mode.

That's not really the question I'm asking.

This device supports both 3 AND 4 byte addressing. It successfully boots in 3 byte mode and I can successfully read and write in 4 byte mode in my application. If you force users to configure ONLY 3 byte mode, they cannot then use devices greater then 128Mb. Nowhere in the TRM or datasheet does it say you must use only 3 byte addressing for all conditions, it only says you must use 3 byte addresses at boot time. I have shown that I am using 3 byte addressing at boot time including when the PORz is asserted.

If your proposal works for me, that's great. But your proposal puts a constraint on the flash device that is not present in the TRM as far as I can tell. Something doesn't add up.

Hi Rijohn,

Thank you very much. I made the 3-byte address changes* to SBL and Application. The latter can now write to flash but most importantly this solves the issue for me, the RBL now boots SBL.

So it seems then that a software reset request ostensibly changes the addressing mode to 3-byte (CR2V.ADP and CR2V.ADS =0) but empirically it does not. There must be some other factor which means the flash device is not capable of talking to the RBL. Anyway, I'm going to quit while ahead and forget about it.

*BTW, changing the deviceBusyType produces no change in the SysCfg code but it seems to work regardless.

Thank you for taking the time to write explanation and rationale.