This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
We are using the XAM6546ACDXEAF on our custom board and are trying to enable CA parity on the DD4 SDRAM we are using. We have used AM65x_DRA80xM_EMIF_Tool_2.03.xlsm from Texas Instrument to configure the SDRAM. We have tested without CA parity enabled and it works OK.
To enable CA parity, we change Parity Latency from 0 to 4 tCK (speed bin 1600 MT/s) in Step2-DDR Timing (AM65x_DRA80xM_EMIF_Tool_2.03.xlsm). This change results in a change in the DRPHY_MR5_DDR4 register (CAPM=1) and some of the time registers are increased by 2 tCK (Parity Latency/2). We have also manually set the PARITY_ENABLE bit in the DDRCTL_CRCPARCTL1 register.
Initializing the configuration with CA parity enabled gives us no errors but writing and reading back from memory just gives us garbage. We have exported and tested both the GEL and RTOS file from AM65x_DRA80xM_EMIF_Tool_2.03.xlsm, with the same result.
Are there any additional changes we need to make when enabling CA parity?
Regards
Johnny Mostraum
Hi Johnny, sorry for delayed reply.
There are several TMG registers which would change when enabling CA parity. Can you provide your with/without parity enabled config files from the tool so i can do a diff. Just want to make sure all of the parameters with additive PL are correct
Also, have you tried initializing with CA parity disabled, then enabling it after training. Maybe there is some inadvertent error propagating.
Regards,
James
Hi James, thanks for your reply.
Attached are the configuration files with/without parity enabled.
We have also tried to activate parity after training, and it looks pretty much like if we do it before training (writing and reading back from memory just gives us garbage).
We use Board_DDRInit from the TI RTOS PDK (8.0.0.36) when doing the initialization.
Regards Johnny
Enable parity:
/* DDR Mode Register 5 */ HW_WR_DDRPHY_REG32(CSL_EMIF_PHYCFG_MR5_DDR4, DDRPHY_MR5 | 0x00000001); /* DDR Mode Register 5. Enable parity (C/A Parity Latency=1=4). */ HW_WR_REG32((CSL_DDRSS0_CTL_CFG_BASE + CSL_EMIF_CTLCFG_MRCTRL1), DDRPHY_MR5 | 0x00000001); /* Write DDR Mode Register 5. */ regValue = HW_RD_REG32(CSL_DDRSS0_CTL_CFG_BASE + CSL_EMIF_CTLCFG_MRCTRL0); regValue |= 0x80005000; HW_WR_REG32((CSL_DDRSS0_CTL_CFG_BASE + CSL_EMIF_CTLCFG_MRCTRL0), regValue);
Hi Johnny,
still not quite sure why this is not working. I did find the following in the documentation, that you also have to update the INIT6.MR5 registers so it is aligned with the SDRAM reg:
If any part of the SDRAM’s MR register is updated by software, it is also the responsibility of the software to
update corresponding INIT*.*mr* so that it is aligned to the SDRAM’s MR register. For DDR4, INIT*
registers are used to control some run-time functionality (such as CA parity), and for automatic mode
register accesses.
See it this makes a difference.
Regards,
James
Hi James,
It was not possible to update the INIT6.MR5 register after training (static register?). We have tested with C/A Parity Latency disabled (0x480) and C/A Parity Latency = 4 (0x481) in the INIT6.MR5 register in initialization with the same result (writing and reading back from memory just gives us garbage).
Regards Johnny
Johnny, INIT6 is what's called a quasi dynamic register which requires SWCTL.sw_done=0 to be able to write to. This may be why the write is not working. Then set SWCTL.sw_done back to 1 to complete the write.
Regards,
James
Thanks James, I manage to set INIT6.MR5 after initialization, but the result is the same (writing and reading back from memory just gives us garbage).
Regards Johnny
Thanks Johnny, still not sure why you are having issues with this. Let me ask some exploratory questions, some of which might be basic, but just for completeness:
-can you try clearing the CA parity error status in MR5 before enabling CA parity. This is to ensure no errors are registers before enabling it
-Can you probe the PAR signal to see if it is at least toggling? If you employ VTT termination, is PAR VTT terminated?
-Do you see an error? Either by reading MR5[4] or by probing ALERT_n?
-Do you have any unused address signals on the DRAM?
-Do you have persistent mode enabled in MR5[9]? My understanding is that if this is disabled, you would only get one error, and the DRAM will proceed to operate normally (without checking for CA parity)
-based on your reg dumps, you have crc_parity_retry_enable=0, so my expectation is that if there is an error received, the controller will not attempt to retry sending the command. So, i think this is a proper setting for now, at least until we debug this
-to try to narrow down a read or write problem, an experiment to try may be to write a small block of memory with parity enabled, turn off parity, and then try to read that block. Similarly, write the block with ca parity disabled, then try to read with ca parity enabled.
Depending on some of the results above, there might be something wrong with the latency adjustments when ca parity is enabled.
Regards,
james
Hi James
We clear the CA parity error status in MR5 before enabling CA parity.
We have examined the PAR signal and it is toggling. PAR is VTT terminated (termination resistance 39.2 ohms)
We cannot see any errors either by reading MR5[4] or by examining ALERT_n.
All the address signals on the DRAM are connected.
We have tested both with persistent mode enabled and disabled in MR5[9].
Test
Parity disabled:
mem write address: 0x80000100 value: 0x87654321
mem read address: 0x80000100 value: 0x87654321
Parity enabled:
mem read address: 0x80000100 value: 0xffffff00
mem write address: 0x80000100 value: 0x12345678
mem read address: 0x80000100 value: 0xffffff00
Parity disabled:
mem read address: 0x80000100 value: 0x87654321
Regards
Johnny
Johnny, since you are not getting any parity errors, it seems like there is a problem with the latency timings, and i think i know where the problem is. The databook mentions this:
For DDR4: RL= CL+AL+PL; WL= CWL+AL+PL
But I'm noticing the spreadsheet doesn't account for the +PL wherever RL or WL is used in the timing registers. For example, DRAMTMG2 defines WL, but the spreadsheet does not add in +PL (based on a diff of the files you sent).
I did a quick search and WL and RL are used in formulas in DRAMTMG0/1/2. Would need to ensure each of these parameters are increased by 2 (PL=4, but because of the 1:2 frequency ratio mode, it would only need to be a +2 for the parameter value) whereever RL or WL are used in the formulas for that bit field.
Regards,
James
I tried to update those registers, but it still does not work.
I have also tried enabling CA Parity on the AM65x Industrial Development Kit (TMDX654IDKEVM) that I have with the same result. Should the CA parity work with the development kit? And if so, is it possible to have the configuration?
Regards
Johnny
Johnny, can you send the full configuration file with your final edits so I can do a diff with the other files sent earlier
My expectation is that this also should work on the IDK, but I don’t think we ever enabled it on that board to my knowledge
thanks,
James
Johnny, thanks.
Just a warning that i will be out of the office for the next 2 weeks and won't have a chance to look at this until after i get back. Let me know if this is acceptable.
My impression so far is that this is not a bug and that i just need to work on the proper latency timings or some other configuration issue. I am not aware of any bug or errata associated with this.
Is CA parity a requirement for your product? Can you make progress without it at least for the next couple of weeks?
Regards,
James
Hi James,
CA parity is a requirement for our safety product. The project will not stop if we wait a couple of weeks, but a solution to the problem as soon as possible is appreciated.
Regards
Johnny
Greetings Johnny,
James will be out for a couple of weeks and we require his input to make progress on this issue.
Thank you for your patience and understanding.
Sincerely,
Lucas