CCS/TMS320F28379D: PPB Post Processing Bloc OFFSET sign extension

Hi Renato,

For the SOC you are converting and assigning to PPB1, can you also check the value of results register ADCRESULTSx (x=SOC#) in addition to the PPB1RESULT?  Wanted to see if the raw results without the PPB OFFREF correction makes sense in the first place.

Thanks!

Joseph

Hi Joseph,

I have looked at it. The ADCRESULTS is always around 2033. No jumps in the result. I think the problem is in the PPB. I saw in the document sprz412 the following: 

Does it apply to my case? Also, where do I check these revisions?

For now I am solving the problem using the ADCRESULT, but I would appreciate if I could figure out this problem.

Thank you,

Renato

Hi Renato,

The errata is only relevant if you are using PPB trip points to create an event/interrupt. It should not affect your application if the trip detection in PPB is not used. Probably not relevant here but die revision, if you are interested to know how to decode would be visible in the package marking. It can be found at the last line (usually the third character in the string YFX-YYZZAAA (where X will be the character for the die revision).

Back to your issue, looks like the result is a signed sum of the actual converted value and the intended offset. Are you enabling the two's complement in the PPBCONFIG register. Can you try switching this bit and check the PPB results again?

Thanks,
Joseph

Hi Joseph,

I recorded the register at real time and I am sending attached. You can see that the ADC result works fine, but not the ADCPPBRESULTS. I manually switched the two complements and the error continues.

Thank you,

Renato 

ppbError.zip

Hi Renato,

Thanks for sending the video file.  To me, it appears like there is a delay in updating the entire 32-bit word for ADCPPB1RESULT in your video clip where transition from a negative to positive PPB result carries the previous sign, hence you would see FFFF0001 to 0000FFFF.  Have you tried reading the entire ADCPPBxRESULT word and deconstructing SIGN and PPBRESULT fields every after conversion?  This should give the correct result and sign.

I was able to reproduce what you were seeing by setting OFFREF to 2033 and having the ADC input signal set to around 1.24V.  This would produce errors of around +/-1 code around 2033 in 12-bit mode and perfect to use for this example.  I think this is a result of CCS display not updating real time (seems to me that update is done 16-bit at a time for a 32-bit word) and this would seem to explain what you are seeing.  Reading ADCPPBxRESULT.SIGN and ADCPPBxRESULT.PPBRESULT immediately after conversion (not relying on the watch window) always produced the correct results for me.

Regards,

Joseph