ADC frequency limit for ADCxDC2 use in STM32F446 (AN4073)

[vvp]

AN4073 states that ADCxDC2 can be used only if ADC frequency is at least 30 MHz. I used it by mistake with ADC frequency 22.5 MHz. It seemed like it improved the precision by about 5 LSBs. The software worked just fine: no crashes, no funny misbehaving.

 

AN4073 does not refer STM32F446 as applicable MCU. STM32F446 reference points to AN4073 as relevant. Therefore there is conflict between these two documents.

 

That leads me to think that the 30 MHz limit may be a mistake as well. Or was I very lucky?

 

It would be fine to have a better explanation what ADCxDC2 exactly means so that I can have some clue about 30 MHz limit. AN4073 states only this: "it masks the internal flash noise during the last ADC sampling cycle". Which is rather vague. Any ideas?

[STTwo-32]

Hello @vvp and welcome to the ST Community :smiling_face_with_smiling_eyes:.

As you can said, this application note it is note applicable on the STM32F44x MCUs:

"STM32F446 reference points to AN4073 as relevant" what do you mean exactly? What are the STM32F446 references that points on the AN4073 as relevant?

Best Regards.

STTwo-32 

[vvp]

Hi STTwo-32,

The picture you posted from AN4073 mentions only these STM32F4 MCUs as applicable:

STM32F405, STM32F407, STM32F415, STM32F417,STM32F42x, STM32F43x.

AN4073 is not applicable to STM32F446 since neither STM32F446 nor STM32F44x is in the list. Nor is the list open ended ... e.g. ending with ellipses, something like "STM32F43x, ...)".

 

But here is a picture form STM32F446 reference, which points to AN4073:

The description of ADCxDC2 refers to AN4073 like this:

"1. Refer to AN4073 on how to use this bit."

Errata for STM32F446xC/xE refers AN4073 is a similar way.

 

It just looks like the list of applicable MCU in AN4073 is not complete (i.e. it is missing STM32F446).

 

That only looks like a minor documentation bug. I'm more interested in a better description how ADCxDC2 works and why it seems to be working despite my ADC frequency being only 22.5 MHz.

 

Thanks,
vvp.

[STTwo-32]

Hello @vvp 

Thank you for reporting this. I will check this internally and get back to you as soon as possible.

Have a nice weekend.

STTwo-32 

[STOne-32]

Dear @vvp ,

If I remember well ,  Indeed all STM32F4 MCUs designed after the STM32F427/429  - more than 10 years ago , have the same ADC bits to improve the accuracy. This Option 2 is a bit dangerous in case of ADC Frequency is less than 30MHz as such value is not by chance but is the Highest value for Flash Wait state  0 as below and indeed depends on Voltage range :

To activate this Option , we should ensure that our customers software is protected and so it consist on disabling ( gating) by hardware any access to the flash fetching during the sampling phase and ensure the timing window will fit correctly . If not CPU can access the Flash while the clock is stopped to flash and so make a hard fault or something like .

With @STTwo-32 , we will be back to you on clear action plan .

Hope it helps you.

STOne-32

 

[vvp]

@STOne-32: Thanks.

 

Just to summarize as I understand it.

 

1) Beside other things, ADC noise is caused by flash access.

2) Option1 and option2 in AN4073 allow to disable flash access from prefetching.

3) Option1 ADCDC1 bit is kind of redundant. It can be used only when prefetch (PRFTEN) is OFF. It masks all flash accesses generated by the prefetch mechanism. I said ADCDC1 is kind of redundant since these accesses could be disabled automatically just by virtue of prefetch being OFF. No reason for the prefetch mechanism to generate them when prefetch is OFF.

4) Option2 ADCxDC2 is actually interesting.It masks flash access from prefetch but does so only during the last ADC sampling cycle. In other words, it adds 1 ADC cycle of latency to flash prefetch in an asynchronous manner.

5) Flash prefetch masking is done by halting prefetch clock. This will increase flash latency.

6) CPU core can tolerate only as much additional latency caused by ADCxDC2 as defined in LATENCY bits of FLASH_ACR.

 

The problem is that point 6 does not seem to be true. My STM32F446 runs at 180 MHz. Voltage is 3.3V. LATENCY is set to 5.  But it seems to work just fine with ADC frequency 22.5 MHz and ADCxDC2 on.

I guess I could change LATENCY to 7 and then it should work OK (180/(7+1) = 22.5 MHz). It would be quicker than lowering CPU frequency to 144 to achieve ADC frequency of 36 MHz.

Or I just let it be. ADC precision is not seem to be a big deal for me.

 

[vvp]

OK, I did one more test just for the fun!

 

I lowered the ADC frequency form 22.5 MHz down to 11.25 MHz. The system seems to work just fine. No unexpected behaviour. PLL output is 180 MHz, AHB prescaler set to 1, i.e. CPU clock is 180 MHz. APB2 prescaler set to 2, i.e. ABP2 peripheral bus at 90 MHz. This is how I did run this firmware for years. I'm pretty sure it is correct. Below are the changes I did to test 11.25 MHz ADC frequency with ADCxDC2:

(gdb) p /x ((SYSCFG_TypeDef*)0x40013800)->PMC
$7 = 0x70000
(gdb) p /x ((FLASH_TypeDef*)0x40023C00)->ACR
$8 = 0x705
(gdb) p /x ((ADC_Common_TypeDef*)0x40012300)->CCR
$9 = 0x830000
(gdb) 

 ADC prescaler (ADC_Common.CCR) is set to DIV8 from APB2, i.e. 90/8 = 11.25 MHz. Flash latency stayed at 5 wait states (FLASH.ACR). ADCxDC2 bits are set in SYSCFG.PMC.

 

I'm pretty sure ADC is slow now like molasses since I see it in my diagnostics showing much less time available to process the ADC output (since it is arriving later). It seems to work just fine despite not obeying the 30 MHz limit by a lot now. I tested this only on my break out board. I did not test this on my full test system and therefore I do not see how much ADC output error changed. But obviously it is not crashing nor does it seem to return bad results. Which is strange. As I mentioned before I did test this with ADC clock at 22.5 MHz on my full test system before. It was by mistake. That run have shown about 5 LSBs improvement in ADC precision.

 

I'm not willing to test this on my full test system until I do know that ignoring 30 MHz limit will not lead to undefined behaviour. My full test system can gracefully recover from HardFault or other unexpected interrupts/exceptions. I can risk those easily. But it may misbehave badly if CPU would behave in an undefined way (e.g. wrong results when reading instruction stream from flash, branching or doing arithmetic operations badly etc.). That could lead to my test system self destruction in a rather spectacular way :)