XMC4200 VADC Background Source blocks - intended behavior ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
funkyluke
Level 2
Level 2
5 sign-ins First like received 10 replies posted
Hi,

I'm currently experiencingbehavior of the VADC background source that does not fit with my expectation 😉

I have multiple channels of both VADC Groups added to the background source and I'm using FIFOs on most of them.
During startup I have to check one of the channels multiple times before the RTOS starts up and I noticed that my code gets stuck there waiting for the VALID Flag after the first read.

Further Investigation revealed that BRSPND has one pending bit left, which seems to prevent reloading of BRSSEL into BRSPND.
The reason for this seems to be that the Result Register of this Channel has the Wait-For-Read Flag set as suggested when a FIFO is used (it is not set on the other channels). If I use the debugger to clear the Valid Flag, the BRSPND Register is reloaded and the application continues.
That raises a couple of questions:


  • Why does a WFR flag block the complete queue/source and not just this channel?
  • Is this intentional?
  • How can this be avoided?
  • What exactly does WFR do with ADC FIFOs? Why does it need to be set on the Input Stage and not on the Output stage? What happens if this is reversed?
  • Is there a simple way to trigger a complete BRSPND reload - Writing to BRSMR/LDEV does not do it, although the RM says it does.


Regards,
Lukas
0 Likes
0 Replies