The Power Quality Library Software and CRC

Assuming that this SPI_CRCCALCULATION_DISABLE is meant to remain unchanged (presumably compatibility issues with the STM32) and the example software doesn't seem to be reading the trailing 16 bits for the chips appended CRC - does this mean that we would need to add extra code (manual CRC calcs) if we wanted to do proper validation on the receive side?

After further investigation I found a number of problems after enabling CRC checking.

1. PROBLEM #1: If CRC is enabled and you read a 32-Bit registers on the console using the "getreg" command,  the console returned  "Warn :RegData.Address Not Available".
   • This warning was sent because a CRC error was detected in the code. 
2. PROBLEM #2: If CRC is enabled and you read a 16-Bit registers on the console using the "getreg" command it displays the "register contents". After looking into it,  the only reason why 16-Bit Registers work is because the code that reads the 16-Bit Registers does not return a status. If the status was returned it would see the same failure that occurs when reading a 32-Bit Register. 
   • I reported this error to STM and they confirmed it was a coding error that needs to be fixed. 
3. PROBLEM #3: If CRC is enabled and you read a 16-Bit registers on the console using the "getreg" command the register contents displayed to the screen are rotated.  The example below shows the results of reading  the  16 bit CONFIG1 register with CRC enabled and disabled. This messed me up because I was looking at the BURST_EN Bit (bit 11) and due to the rotated data it looks like BURST_EN is off.  The ADE9430 does not return a CRC when BURST_EN is on, instead it returns the last register read. 
   • CRC ENABLED: Config1 Register = RegData.0x0208  (rotated) (Bit[11] Burst Enable off) (rotated the data before displaying it. 
   • CRC DISABLED: Config1 Register = RegData.0x0802 (actual)   (Bit[11] Burst Enable on) (correct data)
   • I modified the 32-Bit register code so it would not return a status like the 16-Bit Code and confirmed the 32-Bit Register contents were displayed to the console and they were also rotated. 
     • CRC ENABLED: ADC_REDIRECT Register = RegData.0x1FFFFF00  (rotated data) 
     • CRC DISABLED: ADC_REDIRECT Register = RegData.0x001FFFFF  (correct data) 
4. PROBLEM #4: When you enable CRC in the code it does not turn off BURST_EN so the ADE9430 does not generate CRC. Instead it returns the last register read. 
5. PROBLEM #5: Next I manually turned off BURST_EN in CONFIG1 and left the 32-bit Register code with the change to prevent CRC status from being returned. I then read 16 bit and 32 bit registers.
   • Using the scope I verified the ADE9430 was returning correct CRC. 
   • However, the register data displayed to the console was shifted left by a byte and the first byte of the CRC replaced the last byte of the data. see table below. 
   •  

I also identified a few other issues wit the timing on the  SPI bus as well. I posted these questions to the STM site and no one could answer why the timing was off. 

The reason why CRC does not work is because there appears to be a compatibility issue between the ADE9430 CRC operation and the NUCLEO-144 STM32F413ZH processor CRC operation. I confirmed this with the STM engineers. 

• The ADE9430 uses a 16-bit CRC (CRC-16-CCITT) which is calculated across all the data sent, it then transmits a 16-bit CRC at the end of each SPI bus transmission. The receiver of the data generates its own CRC over the data and compares it to what was sent.
• Meanwhile, the NUCLEO-144 STM32F413ZH processor datasheet indicates it uses CRC-32-CCITT. However, the datasheet also indicates it should be able to handle a CRC8 or CRC16 depending on the SPI bus Transfer size.

If they are incompatible why not state this in the EVAL-ADE9430 documentation?