Why NOR mode can't work with GPCM for IFC at the same time ?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why NOR mode can't work with GPCM for IFC at the same time ?

Jump to solution
1,600 Views
dfxhappy
Contributor II

As our custom T1042 board, IFC controller connect a 32MB nor flash(16-bit width) by CS0 and connect a 8-bit CPLD by CS2. CS0 was configured with NOR mode through MSEL bit of OR. and CS2 was configured with GPCM mode through MSEL bit of OR. There's no problem if access each at different time, but if accessing the CPLD, we do erase/write to nor flash, it will make the read/write CPLD not reliable, all registers read from CPLD turn-ed to be all zeros. That's very strange. once this problem happened, the cs signal of CS2 for CPLD seems to be abort-ed by IFC controller. we dump-ed the 0xFFE125800 register, it's value turn-ed to be 0x00400000, that means the transaction to CPLD was abort-ed during erasing/writing to NOR flash. 

But If I turn the CS2 MSEL into NOR mode. the word turn to be peace. But I can't explain the problem, there may be some potential design bug for IFC controller side.

Log when problem happened

fffd40400 : 03 00 c3 09 03 00 c3 09 03 00 c3 09 03 00 c3 09 : ................
fffd40410 : 07 00 c7 09 07 00 c7 09 07 00 c7 09 07 00 c7 09 : ................
fffd40420 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40430 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40440 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40450 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40460 : 08 00 c0 0b : ....
0x00000000
fffd40400 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
fffd40410 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
fffd40420 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
fffd40430 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
fffd40440 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
fffd40450 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
fffd40460 : 00 00 00 00 : ....
0x00400000

.......

After 5 seconds after the NOR flash erase and write complete, accessing CPLD turn to be good again.

fffd40400 : 03 00 02 00 03 00 02 00 03 00 02 00 03 00 02 00 : ................
fffd40410 : 07 00 02 09 07 00 02 09 07 00 02 09 07 00 02 09 : ................
fffd40420 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40430 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40440 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40450 : 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b 08 00 c0 0b : ................
fffd40460 : 08 00 c0 0b : ....
0x00400000

1 Solution
1,399 Views
Bulat
NXP Employee
NXP Employee

Background is quite simple, in case of GPCM RB0 signal acts as IFCTA_B, if asserted (like in your case) it aborts transaction to CPLD. When you re-configure CPLD to NOR FLASH machine, there is no such a problem/effect.
Yes, you can use a workaround as you described if HW changes are unwanted. Note however, schematics is not correct anyway, I do not see a pull-up resistor on RB0 signal, or it is placed somewhere outside of visible area. Typically RY/BY# signal of NOR flash devices is an open-drain output, i.e. it can pull down the signal, but pulling up should be provided by an external pull-up resistor.

Regards,

Bulat

View solution in original post

8 Replies
1,399 Views
Bulat
NXP Employee
NXP Employee

What is the connection of flash's RY/BY# signal in your design?

Regards,

Bulat

0 Kudos
1,399 Views
dfxhappy
Contributor II

RY/BY of NOR FLASH connect-ed to IFC's IFC_RB0_N

ready_nor_flash.jpg

CPU IFC side's RB0 signal

RB0_1.jpg

General other signal of IFC (CPU side)

ifc_nor_flash.jpg

Do you need more signal from the design?

0 Kudos
1,399 Views
Bulat
NXP Employee
NXP Employee

I believe the problem is really due to RY/BY# signal connection. It stops IFC normal operations when asserted. In fact the NOR flash does not need to report "busy" state to the controller, so you need 1) to remove flash's RY/BY# to CPU's RB0 connection and 2) to pull up unused RB0 signal. This will solve your issue.

Regards,

Bulat

0 Kudos
1,399 Views
dfxhappy
Contributor II

hi, Bulat,

If it's possible to not change the HW, just change the CPLD's IFC mode from GPCM to NOR mode. IMO, as to NOR mode or GPCM mode, as to CPLD side, IFC just took it as memory area, it will just re-use the OE/WE signal to take read/write. Kindly please evaluate the software work around for this. I have no idea about the IFC logic and timing design. Also I don't know the impact if change the mode, also can't explain why if changing to both NOR mode, that can work. Just change the mode but keep the default timing settings register for NOR mode of CPLD. IMO, it should keep the slowest timing for CPLD access. Since lots HWs have been deployed, and NOR flash is seldom to be updated. the problem only happened during system image upgrade. We just need to find a valid and minor impact method to go over it. While we need to make sure the SW wa have no side affects during system image upgrading. our WA is: during upgrading the NOR flash image(just boot loader), we will change the CPLD's IFC mode from GPCM to NOR mode. after upgrade complete, board will be reset and restart, after restart, all settings will be kept as before. 

BR

Fisher Duan

0 Kudos
1,400 Views
Bulat
NXP Employee
NXP Employee

Background is quite simple, in case of GPCM RB0 signal acts as IFCTA_B, if asserted (like in your case) it aborts transaction to CPLD. When you re-configure CPLD to NOR FLASH machine, there is no such a problem/effect.
Yes, you can use a workaround as you described if HW changes are unwanted. Note however, schematics is not correct anyway, I do not see a pull-up resistor on RB0 signal, or it is placed somewhere outside of visible area. Typically RY/BY# signal of NOR flash devices is an open-drain output, i.e. it can pull down the signal, but pulling up should be provided by an external pull-up resistor.

Regards,

Bulat

1,399 Views
dfxhappy
Contributor II

One more question, if change the CPLD into NOR mode, since there's no RB signal to make the IFC controller know who is busy? Will it impact the NOR flash's erase/write during read/write CPLD at the same time? since as to GPCM, RB will be asserted to abort CPLD operation. IFC make sure only nor flash operation ongoing.

0 Kudos
1,399 Views
Bulat
NXP Employee
NXP Employee

I do not clearly understand your question. On the one hand the controller can not know "who" asserted busy signal (if several CS's share the same RBn). On the other hand the controller does not need this information. I already wrote, the NOR flash does not need to report "busy" state to the controller via RB signal, so this connection can be removed at all without any problem.

I also believe your CPLD is not connected to RB0 signal, so no problem here.

Probably your question is answered? let me know if not.

Regards,

Bulat

0 Kudos
1,399 Views
dfxhappy
Contributor II

Yes, you're right, from NOR flash datasheet, need a pull-up in advice

Really thanks for your reply. Really helpful to understand the problem more clearly we met.

BR

Fisher Duan

RB_SIGNAL_FROM_NOR_FLASH_DEF.jpg

0 Kudos