STM32L476 SPI3 Using DMA2 Chan 2. No Transmit.

[shingadaddy]

Hello Everyone. My how the forum has changed. Just dropping a recent odd experience here to see if anyone might have any comments. No. I don't use CubeMx and no this isn't another 3 year anniversary item regarding initializing the DMA before any peripherals that use it. We do that by default. However - working on a colleagues project, I have some code written to do some work that IS HAL library style stuff.

Getting a DMA controlled transmission from SPI 3 from the micro.

I have a DMA transmission from SPI 1 working. So I am familiar…….

Second Saturday in a row working on this for SPI3…..    Nothing I try works when using the DMA approach.

I can get all the SPI 3 hardware to work and send data if I call the BLOCKING SPI routine. NOT using the DMA.

Dumped out tons of register settings – All looks as it should.

Finally I give in to what I figure is a LOOOOOOOOOOONNNGGGGGG shot . --------              Try a different board.

It appears to work.  (???????????????)

Mind you --- the first board works with everything EXCEPT a DMA transfer for SPI3. Leads me to believe that – the micro has a BURRIED PERIPHERAL BAD ? One that has NO OUTSIDE WORLD HOOKUPS ?

*THAT*   will definitely be a FIRST for me.  I don’t know if I believe what I see until I try this on several boards.       I have 4. Of course -  I'm spooked about some sort of configuration weirdo that allows some race to occur that will maybe work on some chips and not on others.  My only question would be ---  Suggestions as to Where? I have this set up to test as a 1 pass event then trap it after the call to HAL_SPI_Transmit_DMA(&Spi_3_Handle, source, 33840). So not getting a loop around recall. And yes I always  wait after enabling clocks .

How rare is the bad burried peripheral idea?

Any feedback appreciated!

Thanks.

R

[waclawek.jan]

> Creating separate hdma1_tx and hdma2_tx structs seems to have done the trick.

OK so this is a case of improper use of Cube/HAL, isn't it.

Yes, this boils down to appropriateness of accompanying documentation, availability and readability of relevant examples, etc. I believe this is a well known thing.

Please click in post telling the solution the "Accept" button, so that the thread is marked as solved.

JW

[Piranha]

Trying to adapt to all types of people means adapting to dumb people. If you do that, the result is that the product is "useful" only for dumb people. That is what CubeMX code generation is doing. And the idea of the code generation comes from 90ies, when it was over-hyped by university professors, who cannot develop a real software product anyway. It does not work and cannot work, because even to know what to click, one must still understand how the device works and therefore still read the reference manual. 

The HAL has a different set of problems - it is over-abstracted, under-abstracted and all of the code is broken. 

I myself started with a desktop PC software development and that knowledge actually helps for embedded development. I can design a real life large and complex modular software with many components and abstraction layers, write proper asynchronous and multi-threaded code etc., none of which ST's "experts" and typical electronics engineers are capable of. You mentioned the superloop architecture... Well, that is a perfect example of how stagnant and stuck at a primitive level the whole software industry is. Any decent software is event triggered, regardless if it's based on a simple single stack cooperative scheduler, RTOS or a huge desktop level OS.

[Pavel A.]

Great. :thumbs_up:

[shingadaddy]

Just droppped in to finalize. Thanks everyone for the feedback.  And thanks Pavel A. for the kudo!

This may serve as an example for the less experienced attendees who might get this far - of what you might run into if you rely on HAL for some quick fix under a short fused project. Don't get too discourage at working at the HAL level but understand that it is not the cleanest or most polished solutions. Time and more experience will help as you go on. Remember HAL is FREE. And - you get what you pay for. 

Why didn't someone tell me "you don't need brackets dummy"? 

Health Happiness and positive learning experiences to you all in the coming New Year. !

R.

[Pavel A.]

Wait wait. The problem was caused by the code generation. "HAL" is the library, it is independent from the code generation. With all criticism thrown at it, mostly it is "good enough" for a quick prototype. 

>  Remember HAL is FREE. And - you get what you pay for. 

Kudo to you again :)

[shingadaddy]

Yes.   Prototypes which many times turn into solutions for quick turn one off projects. 

And in THIS case - the "code generation" is done by ...............   ME! ... :) 

Not CubeMX. 

"I" don't use CubeMX. 

Now of course - I'm tempted to try CubeMX with 2 SPI busses set up with both using interrupts and DMA to see what it spits out. But unfortunately - that would be pointless in the existing SCHEDULED activities here.