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

AURIX™ Forum Discussions

User20639
Level 2
Level 2
First like received
I have a special application using 24 PWM outputs. I am updating the duty on all 24 outputs every PWM cycle, and want to run at high switching frequency (30kHz+).

The problem is that writing to all 48 registers (SR0, SR1 for each TOM channel), takes a lot of time, about 7-8us when running at the TC299's max frequency of 300Mhz.
My whole task (adc/resolver read, current control loop, duty calculation, writing to registers) takes about 26us, so 25% of it is writing to the registers.


The code is as follow:
/* writing to GBL_CTRL to disable updates */
GTM_TOMx_TGCx_GLB_CTRL.U = xxx

/* writing to TOM Shadow registers*/
GTM_TOMx_CHx_SR0.U = PeriodArray[0];
GTM_TOMx_CHx_SR1.U = PeriodArray[1];

/*above code repeated for each of the 24 TOM channels*/

/* Enable updates again */
GTM_TOMx_TGCx_GLB_CTRL.U = xxx


My question is: is there anyway to make it faster? Is this normal to take that long?

Thanks!
0 Likes
6 Replies
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
The GTM is pretty slow on the SPB. Is PeriodArray in local DSPR? That will only help a tiny bit.

You could make a gigantic DMA linked list to do the transfers from PeriodArray into GTM_TOMx_CHx_SRx. That would reduce the CPU stall to just the time of kicking off DMA.
0 Likes
User20639
Level 2
Level 2
First like received
I think this one lives in Pflash. I'm not currently using the PSPR/DSPR areas.
I can have a look into moving it there, see if that helps.

I'll also have a look at using the DMA more. I've noticed it takes quite a while to return my ADC results, I can probably speed that up using the DMA as well. I've seen there are code examples for this, I'll give it a go.

Thanks a lot for the suggestions!
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Possibly important to note that using DMA isn't really faster, because there's a bit of overhead in arbitrating between DMA channels and swapping transaction sets in and out. A good general guideline is that a DMA transfer will complete within 400 ns.

Offloading those moves to DMA gives you more CPU bandwidth, so in that sense, it's faster 🙂
0 Likes
User20639
Level 2
Level 2
First like received
That's a good point. I'm not so much after pure speed, even though I'd like to run that task at >50kHz. It's more like getting the CPU to do actual calculations, not waiting register writes!

My input processing will certainly be interesting. The TOM generates an interrupt at 50% duty, which triggers the ADC sampling, which generates an interrupt at end of sampling, which will trigger the DMA transfer, which will generate an interrupt and trigger the rest of my task once the data is ready! Nothing can go wrong 😄

I'll update the post to report on my progress.
0 Likes
User20639
Level 2
Level 2
First like received
FYI, this seems to work!

I've done a linked list to transfer the 6x ADC results, it didn't save a lot of time, but it's nice to have.

I also implemented a linked list to move the 48 TOM Shadow Registers, this ended up pretty much saving 5-6us (pretty big for a task running up to 30kHz). I'll need to time the DMA transactions, to see how long it takes to copy all the data to the GTM, but at least it frees up the CPU to do actual calculations!

Thanks again for the suggestion UC_wrangler. I'll start using the DMA more.
0 Likes
User20639
Level 2
Level 2
First like received
Last update. It works well, but yes, the DMA transfers are taking quite some time (12us in total). I'll have to make some optimisation, because I don't think a 48 wide linked list is the best way to go, but it's a good proof of concept. Unfortunately, the TOM channels I use are not contiguous, so I cannot take advantage of the multiple moves per transaction capability (with auto source address increment).
0 Likes