AURIX™ Forum Discussions

[#1]

Hi!

I'm currently working on a application that uses the QSPI module on a TC234 micro.

Previously we have been calculating the parity bit by our-self, but right now I want to try out the hardware parity bit calulation instead, to save some CPU load.
This is how it looks on a oscilloscope with my own parity bit calculation:

(I know that the fall/rise curves are soft, but currently I'm not testing against any slave)

This is how it looks when I use the hardware calculated parity bit:


The payload is the same between the pictures, and what I can see is that the payload seems to be shifted to left with one step:
Expected data:
1110010000000001 where the LSB is the parity bit

but with the HW calculated parity bit I get:
1100100000000001

My settings when I use the the HW calculation:
BACON.PARTYP = 0
BACON.BYTE = 0
BACON.DL = 0xE <<-- 15 bits payload + 1 parity bit
ECON.PAREN = 1

Settings when I use my own parity bit calc:
BACON.PARTYP = 0
BACON.BYTE = 0
BACON.DL = 0xF <<-- 16 bits payload
ECON.PAREN = 0


Does anyone know why this is happening when I use the HW calculated parity bit? I can't find anything in the data spec...

[cwunder]

I am assuming your drawings are displaying the LSB (parity) as the left most bit.

The BACON.PARTYP = 0 defines EVEN parity. Your expected data is showing ODD parity (5 Ones).

The AURIX is generating EVEN parity as requested (4 Ones).

What are the data values that you are writing to the SPI (in both cases) as they don't appear to be the same value.

[#3]

A couple of months late answer, but at least I have solved the issue now.
As cwunder wrote, yes PARTYP shall be zero to get odd parity.
But the big problem for me was how I packed the data into the DATAENTRY register.
Before I had one bit reserved for the parity bit, but when I removed that bit and shifted everything the HW parity bit calculation started to work.

[cwunder]

Sorry that you had troubles: I did what to point out that the user's manual does describe how the parity is being generated and used. From the users perspective you don't need to worry about it as it is completely handled int he QSPI hardware (as long as BACON.BYTE = 0)

Parity settings for transmit and receive are defined by the corresponding bit fields in the BACON register.

The parity bit is concatenated to the data bits at transmission time. That means that a frame containing 16 bit data is 17 bits long (data + 1 parity). The transmitted parity bit can be read from the STATUS.TPV bit.

The parity bit is removed from the received bits at receive time automatically. The received parity bit can be read from the STATUS.RPV bit.