43XX: GPDMA Linked List Item reload time

[a_bet]

Hi to you all, as pointed in this (https://community.nxp.com/thread/420407 ) question the GPDMA reload time of linked list items can heavily affect acquisition with ADCHS.
Does anyone know (or tried to estimate) the exact amount of time needed for the reload? As far as I can see there's no info on this on the manual.

Best regards,
Andrea

[michaelhermann0]

Hi Andrea,

I never used "mich0", I'm rather sure about that. I probably used "mch0", since my ususal signature "mch" didn't work.

In addition, I didn't do that much on LPCOpen, some minor bug fix on PLL initialization comes to mind. Furthermore, I haven't substantially contributed to the 43xx section during the last year.

All in all, most probably someone else deserves your thanks.

Nice to hear that your thesis finished well - all the best for your future work.

Mike

[a_bet]

I'm sorry, I meant to write mch0! I used your fixes to LPCOpen for the ADCHS driver and the DMA (I refer to this and this) .. I was struggling a lot since this was my first real project on a micro and I found it quite challenging. I proposed you fixes to a NXP employee in this question because I think they should include them in the next LPCOpen realese, but as for now I haven't see them. So.. ala in all, thanks again a lot Mike!

Good luck to you too,
Andrea

[Carlos_Mendoza]

Hi Andrea,

Such time should be quick as it is hardware loading and just close to 4x memory words read time.

Hope it helps!

Best Regards,
Carlos Mendoza
Technical Support Engineer

[michaelhermann0]

Hi,

there is no such information in the UM and the time seems to be too long to allow for continuous transfer of 80 MSPS. It is rather obvious that the GPDMA controller only starts to load the next list item at the very moment it detects that it can't service the request pending because the current chunk has expired.

I did try every trick I could think of (placing the list items and the buffers into different RAM regions to avoid bus contention, lowering the threshold of the FIFO trigger, even trying to minimize the influence of the independent USB DMA just in case).

It still dropped samples at times.

I also got the impression after a talk to a very nice local NXP application engineer that the whole HSADC was more or less tacked on because it was left over from another product (video) and would give the 4370 a unique selling point.

But the side effects (excessive power drain on the internal regulators, DMA issues) were not contemplated in detail. Since there didn't materialize a real demand (at that time, and I don't think that has changed) for the HSADC there was no real chance for a redesign that would fix known problems.

At least that was my "informal" impression back then.

My advice is to give up on getting 80MSPS transferred to SRAM continuosly w/o sample loss.

Mike

[a_bet]

Hi Mike,
I know I'm late, but still, thanks a lot for the reply. I'm using it @ 40 MSPS and I'm happy with that, I didn't tried to go further. BUT, I guess you are mich0 from LPCware, is that you? If so, THANKS A TON for the work you did on the LPCOpen support for this chip... you really helped me out with my thesis, thanks again.

All the best,
Andrea