Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
I am trying to use a DMA channel triggered by the interrupt on capture feature of a 24-bit UDB counter but the counter seems to be triggering it just once. If I am not getting it wrong XaxCtr_STATICCOUNT_LSB_PTR is a pointer to the last captured value while XaxCtr_STATICCOUNT_LSB is the capture value pointed to by the former (from the code generated for the counter by psoc creator).
#define XaxCtr_STATICCOUNT_LSB (*(reg32 *) \
#define XaxCtr_STATICCOUNT_LSB_PTR ( (reg32 *) \
In the example project I use the same counter configuration that I am using in my application. I am capturing the counter by banging a control register bit while the counter is being fed by a 1 Hz clock. At the start of the program the counter (up & down) is preset to half its counting range so we can go up or down without reaching overflowing or underflowing it. This preset is captured but it stops working there even when the counter keeps counting up which is veryfied by reading it into a variable in the line
ctrval = CY_GET_REG24(XaxCtr_COUNTER_LSB_PTR);
I added a second transaction to the DMA channel that reads the counter status byte in order to clear the interrupt as stated in page 22 of the component data sheet. Is the reading of the status register by a DMA transaction a valid way to clear the interrupt flag? What would be the right way to do it if not?
I am attaching a sample project with the problem (or the doubts about me missing some point). Another worry regarding the counter is the atomicity of the readings (either capture or counter register). While researching for this problem I stumbled upon a thread dealing with that problem (cypress.com/forum/psoc-3-known-problems-and-solutions/udb-counter-and-counter-register-read-operation) and I experienced myself a few strange readings but they were more in the form of a zero reading than an byte overlap because the counter was not changing.