Trap when reading anything other than PFlash0

[User19824]

Hi,

I'm using a TC397-256F and if I try to read the contents of PFlash from a flashloader (via ASC BSL), I can only read PFlash0. As soon as I touch 0xa0300000 or anything above (up to 0xa0ffffff) I get Trap 4 TIN 2 with 0x00000004 in DSTR (Load Bus Error).

The flashloader does not explicitly change any settings and only CPU0 is running. It seems as though CPU0 can only access it's own LPB but LPB_SPROT_ACCENA_R and LPB_SPROT_ACCENB_R are both set to 0xffffffff, and everything I've found in the user manual seems to indicate that access to all flash should be possible by default.

I've also checked HF_PROCONPF.RPRO (even though that applies to the whole of PFlash if I understand it correctly) but it's set to 0.

Are there any other settings that could produce the same effect?

It seems that Memtool has the same problem. It times out as soon as it hits 0xa0300000.

I've just seen I also get the same trap when trying to read from 0xaf400e00 or 0xaf401e00 (UCB). I don't know whether that's related?

Does anyone have any suggestions?

[Darren_Galpin]

To read the other flashes, the access has to go out on the bus to another CPU, so for those any local settings do not apply - you would need to see the settings for the CPU to which the PFlash is attached. So for example, PFlash1 on CPU1, PFlash2 on CPU2 and so on.
The UCBs are located in DFlash, not PFlash, so are read via the DMU, not a CPU - it is as though all accesses outside of the CPU are erroring. If there is a bus error, then the details of the access causing the error should be logged in the XBAR - it should record the address, tag and interface accessed. Do you have that information?

[User19824]

Hi,

Just to be clear, the problems I am seeing with PFlash are as soon as I move out of CPU0's local PFlash block. I can read all of DFlash0 (haven't tried DFlash1 yet) and all apart from UCB7 (UCB_HSMCFG) and UCB15 (UCB_RETEST).

DMU_HF_CONFIRM0 shows that UCB_HSMCFG is CONFIRMED, so that is presumably why I can't read it (read access is apparently only available if it is UNLOCKED).
UCB_RETEST also appears to be CONFIRMED although I'm not entirely sure whether that prevents reads.

Returning to the PFlash issue:
LPB_SPROT_ACCENA_R and LPB_SPROT_ACCENB_R are set to 0xffffffff for all cores.

Do the other cores need to be running for CPU0 to access their flashes? That doesn't appear to be case from the bus diagrams in the user manual. Are there other registers I need to look at?

Regarding XBAR, I've read out address and error registers.

For PFlash at 0xa0300000, DOM0_SCICTRL5_ERRADDR contains the right address (which is correct if I understand it right as SCI5 maps to CPU1P): Addr: 0xa0300000, Error: 0x00cc8126. PIDSTAT: 0x00000000, TIDSTAT: 0x00040000, TIDEN: 0x01ffbfff
For the two UCB blocks (0xaf400e00 and 0xaf401e00), they appear in DOM0_SCICTRL1: Addr: 0xaf401e00, Error: 0x001ec126

I'm not sure what to do with that to be honest. I can separate out the fields of course but after that I'm a bit lost.

Thank you for your help

[Darren_Galpin]

The other cores do not need to be running to access the flashes, as there is a path through which bypasses the part which is off.

The information in the XBAR means that there really was a bus error returned by CPU1/PFlash1, so we know that nothing was wrong with the CPU0 setup or settings. So then we need to try and work out why.

TIDSTAT has bitfield TIDMCI2 set, which means that CPU0 has seen a transaction ID error. A transaction ID error usually means that the data being read has an ECC error in it. Due to the way the SRI interconnect works, you can only indicate a bus error in the first beat of an access, so if an ECC error occurs, we also invert the top two bits of the transaction ID, which forces a transaction ID error in the master doing the read. This would seem to indicate that the data being read had an ECC error in it, and it could cause a bus error if it was the first beat. Has PFlash1 been programmed at all, and contains valid data?

Additionally, if you look at the ERR register, ERR.OPC=0010, which is SDTW - you were trying to read the PFlash with a 32-bit read access. Access to PFlash requires SDTD, BTR2 or BTR4 (please see the NVM chapter, section Program Flash Interface). I believe that you are getting the error because of the bus opcode size used - please try with 64-bit or burst reads.

[User19824]

OK, I ran "Verify Erased Logical Sector Range" on each of the PFlash sectors in turn and found that only blocks in PFlash0 had been written to. All other sectors were empty.

After writing some data to other PFlash blocks, I can read the data back out of them (even with SDTW operations) 🙂

Thank you very much for your help!