Synchronous USART 'clock' not working?

[SBoks]

Hello,

Currently I am working on an ECU to communicate with an (existing) electronic sub-system . My choice was to use the STM32F4 family for this application.

Boards are coming in while writing software and there are issues in testing.

I discovered that the Synchronous UART appears to be 'broken'. It is a little hars and untrue, I know it works according to the datasheet after actually reading it, but my limited experience with synchronous USARTS tell me that the clock should always be present, even when no data is being send. I may be wrong and the USART camp may be divided in segmented clocks and continious clocks, the issue remains...

I need a continious usart clock.

Is there a hidden register back-door in the STM32F4 family? A program method , good document to read ? The usart clock speed is 500kbit/s exact.

Hope someone can help!

[Tesla DeLorean]

Perhaps generating/reading bit streams via SPI?

Driving bit patterns to GPIO via DMA and a pattern buffer, driven by a TIM, reading GPIO via different phase.

Some of the STM32 peripherals are very poorly architected, I say this as someone who actually built single board computers in the 80's, used a lot of MOS, Motorola, Intel and Zilog parts, and programmed PAL/GAL. I learned how to write software, build hardware *before* I learn how to design ICs.

Some of the designs here lack understanding of usage, and use cases.

[henry.dick]

" I may be wrong"

you probably want to be sure first. otherwise, you are trying to solve that problem that doesn't exist.

I would check the uart configuration, and gpio configuration and go from there. If it is a software problem, show your code.

[SBoks]

@ Clive ,

Man you made me chuckle. (I really still like those 8 bitters.)

It is one hell of an idea though. Ill seriously consider it.

DMA to GPIO may be the right bullet to fix useless boards for now. The DMA would not load the cpu much generating the correct waveforms.

I was trying to visualize using a 9th bit to keep the clock running, but that would just move the problem, start & stop bits are not clocked in this USART.

@ Nickname 14573

I am certain I want a continious clock for being compatible with the existing (slave) equipment.

Its not a luxery to try without. Even if the slave equipment works with a chopped clock, it will fail to meet the specifications of a continious clock source. I may not be able to proof it always works under all conditions. (I simply have no inside information of the slave device)

Another method may be somehow to synchronize a timer output to the usart clock and force clock pulses out. Not sure how to implement that idea though.