PIT Triggered UART DMA (possible with LPUART but not with UART?)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

PIT Triggered UART DMA (possible with LPUART but not with UART?)

560 Views
mjbcswitzerland
Specialist V

Hi All

I have been working on high accuracy DMX UART timing with devices with LPUARTs. In some circumstances it is necessary to accurately control inter-character spacing (time delays) and the technique allows zero overhead operation by allowing a PIT DMA trigger to control the transmission points in time.

A reference binary can be found at http://www.utasker.com/kinetis/FRDM-KL27Z.html#UART_TIMER as well as some extra details.

Although I would have liked to do the same for all UART types this hasn't been possible (yet) due to the fact that in order to write data to the data register it is necessary to first read from the UART's status register. This fact is stated clearly in some user manuals (eg. to KL26) but not mentioned in others, where the behavior is the same.

Eg.
pastedImage_1.png

Therefore, the unfortunate behavior of these UARTs (as opposed to the LPUARTs) is that the PIT triggered (and timed) transmission results in only one character actually being sent out even though data is transferred to the UART data register multiple times. Based on this result it would be necessary to use interrupt driven operation to approximate the required behavior (with the additional overhead).

However, it IS possible to transmit based on DMA when the UART's Tx own DMA trigger is used (without the inter-characters spaces of course) and so this raises the question as to how this is possible without requiring a read of the status register at each byte??? The internal mechanism must be doing something to get around this when used like that!

The question is therefore whether there could be some technique to actually allow timer based DMA transmission to be realised? Anyone with knowledge of how this could possibly be accomplished?

Regards

Mark

P.S. A related topic, including some diagrams, is also here: https://community.nxp.com/thread/442382 

Labels (2)
0 Kudos
2 Replies

350 Views
bobpaddock
Senior Contributor III

As I explain in my reply to your https://community.nxp.com/thread/442382 thread I'm using a complex mess of PIT/DMA/TPM to make accurate sounds, which works fine once all the chip issues are figured out.

However I randomly find the LPUARTs lock up when using interrupts, they stop sending.

I have not been able to come up with a simple test case that shows the problem sadly.

It could well be my code, which is standard text book que code (accounting for the atomic issues), that I've been using just fine for other parts for many years.  However with all of the other issues I've run into with the KL27 (I2C, PIT, Bootloader [How did you make out on that, never saw I reply to your KL27 Bootloader thread?]) I'd like to say this is just one more hardware problem.  I'd really like proof of it tho.

0 Kudos

350 Views
mjbcswitzerland
Specialist V

Hi Bob

I am not aware of any LPUART issues and believe that all I2C ones have been worked around in the meantime - I recently updated the I2C master/slave document with some more information):
http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf

There is a KL27 product in operation for about a year which uses intensive I2C and LPUART in interrupt mode (since the DMA channels are dedicated to USB audio operations) and two new ones with intensive LPUART (continuous 250kBaud on both) are just going into production - these use DMA though.
I did start using the KL27 ROM loader in the factory and for initial programming it has been fine, although I didn't need to work around anything since it is only a one-time program after which a secondary boot loader takes over. I must admit that it is practical for emergency programming by people who have no tools (I used the USB loader in ATMEL SAM7X devices for 11 years for factory programming but for general field updates a secondary loader has just too many advantages).

Concerning the KL27 for USB devices - I don't really understand why NXP makes the small ones since then an external regulator is needed. The larger ones have much more memory as well as internal regulator and their additional price is about the same as adding an external regulator to allow a small one to be used....
Generally extremely easy to use device and a recent new HW design (with KL27) and porting of a previous Coldfire product took 29.3 hours to full operation (from work report).

Regards

Mark

0 Kudos