TMS570LC4357: DMA-ed SCI-transmit-packet is a constant (cannot be updated)

I reduced my code to the example_sci_dma.c code. And I added the following while loop at the end:

while (1)
{
   //Loop here, and change the first tx byte
   while ( (dmaREG->BTCFLAG & 0x02) != 0);
   if(RxPtr[0] == TxPtr[0]) { passCount++; } else { failCount++; }
   TxPtr[0] += 1;
   dmaREG->BTCFLAG = 0x03;
   dmaREG->HWCHENAS = 0x03; //Does not update (stays zero)
}

This loop only performs one DMA transfer; I thought clearing the BTCFLAG and setting the HWCHENAS flags would cause another transfer, but I cannot write to HWCHENAS -- it stays zero. The BERFLAG register is zero (no bit error); do I have to stop or disable the DMA (in GCTRL0, then set the HWCHENAS, then re-enable for each new transfer? Essentially I am asking -- what is the code above to cause a repeated DMA transfer?

Thanks,

Jim

Hi Jim,

Can you please refer my first comment in the below thread:

(+) TMS570LC4357: DMA Roll over queiry - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

Here i explained how to reinitiate another DMA transfer after completion of one block transfer.

--
Thanks & regards,
Jagadish.

Jagadish,

Do you have an example that targets the TMS570LC4357 specifically? That LS3137 project will not run on my target -- it loads and then only the red-stop button is available (run and pause are greyed out). I think that means the code is off in the weeds. I changed the target processor to LC4357 and it still won't run.

Thanks,

Jim

I was wrong (in the title of this issue), that the DMA-data cannot be updated -- it is sometimes not updated. 

Let me reword the problem; I am DMAing out a 9-byte SCI-transmit every one second using a hardware trigger. What is supposed to happen is bytes 1-8 are incremented every cycle, and byte 0 = byte 2. Using a DMA-hardware-trigger, byte0 (written to SCI->TD) kicks off the DMA transfer. However the remaining 8 bytes sometimes update and sometimes don't. Here are a few transmissions. See how the full packet updates sometimes, or sometimes goes a variable number of cycles without changing:

02 01 02 03 04 05 06 07 08
03 01 02 03 04 05 06 07 08
04 01 02 03 04 05 06 07 08
05 01 02 03 04 05 06 07 08
06 01 02 03 04 05 06 07 08
07 06 07 08 09 0A 0B 0C 0D
08 07 08 09 0A 0B 0C 0D 0E
09 07 08 09 0A 0B 0C 0D 0E
0A 07 08 09 0A 0B 0C 0D 0E
0B 0A 0B 0C 0D 0E 0F 10 11
0C 0A 0B 0C 0D 0E 0F 10 11
0D 0A 0B 0C 0D 0E 0F 10 11
0E 0A 0B 0F 10 11 12 13 14
0F 0E 0F 10 11 12 13 14 15

I know:
The 9 byte DMA-source-memory-buffer is updated (via inspection and in the debugger)
The DMA transfer is occurring (because 9 bytes are actually transmitted, even though I only write the first one
The DMA-source address properly points to this buffer.

It is as if the DMA peripheral has its own copy of this buffer, and the DMA peripheral is not always reading in the new data. Is that possible?

Thanks,

Jim

Hi Jim,

Can we have a live debugging session? There you can share your screen and explain the problem and i will provide my suggestions to rectify it.

If you are okay with it, then please create one meeting request and share with me.

I will be available from 10AM to 7PM IST (Indian Standard Time)

--
Thanks & regards,
Jagadish.

Jagadish,

Here is a Microsoft Teams meeting invite; we will see if this works. I am in Oregon, USA, Pacific Standard Time, and I believe you are 12 1/2 hours ahead of me, so this 6AM meeting for me should be 6:30PM for you. Please let me know if the time is incorrect for you. We will try for just a 30 minute session, as it is early for me and late for you. I will prepare, so hopefully you can give me some ideas. 

I think this is all you need to join a Teams meeting. 

Meeting ID: 247 507 306 629

Passcode: M9hhDY

Thanks,

Jim

Hi Jim,

jimj2713 said:

so this 6AM meeting for me should be 6:30PM for you.

You are correct.

jimj2713 said:

Meeting ID: 247 507 306 629

Passcode: M9hhDY

Thanks for this meeting, i will login at 6:30PM IST today.

--

Thanks & Regards,
Jagadish.

Hi Jim,

I am waiting for you to join into the meeting.

--
Thanks,
Jagadish.

I show the meeting as tomorrow at my 6:00AM. Hopefully you can join tomorrow.

Thanks,

Jim

Hi Jim,

Okay sure, i will join on tomorrow.

I'm on the call now

Hi Jim, 

Today i didn't get a chance to test this issue due to other issues, i will try to test this on monday.

--
Thanks & Regards,
Jagadish.

Jagadish,

Changing the memory configuration to write-through fixed the issue.

Thanks,

Jim

Hi Jim,

jimj2713 said:

Changing the memory configuration to write-through fixed the issue.

Good to hear that.

Thanks & regards,
Jagadish.