Conflict with GPIO with SDRAM & serial port about ada_drivers_library HOT 11 CLOSED

The pins of the STM32 are configured to route a specific peripheral via calls to "Configure_Alternate_Function". I suggest you download the STM32F429 datasheet document, that describes in detail the various functions that each pin can be assigned to.

You can also try using STM32CubeMX that allows some automated configuration of the pins.

In your specific case, PA9 and PA10 can for example be configured to route the TX/RX of the USART1, using the Alternate Function number 7. This pin configuration has to be performed before the initialization of the USART peripheral.

from ada_drivers_library.

Thanks for the pointer, I've tracked down the table and made more sense of this now. However having tried various configurations and UARTS which I don't think should have any conflicts with the I/O needed to drive the display, every single one I've got working fails once the display has been initialised.

Delving a bit further with a working configuration (UART5 mapped to PC12 & PD2), the problem appears to be around the Initialize_Layer call in framebuffer_ltdc.adb, specifically the call to Fill:

if To_DMA2D_CM (Buffer.Color_Mode) in DMA2D_Dst_Color_Mode then
       DMA2D_Fill (To_DMA2D_Buffer (Buffer), Color, True);
else
         HAL.Bitmap.Bitmap_Buffer (Buffer).Fill (Color);
end if;

I'm guessing that DMA2D_Fill is an optimised fill routine using the DMA engine and it's this that is causing the problem. If I comment this call out and just use the plain HAL version everything works. This is sufficient for what I'm doing in that it's got me something that works however there does appear to be something wrong in this area.

Rgs,

Jon

from ada_drivers_library.

DMA2D is a purely internal peripheral: all it does is performing graphical-oriented memory transfers or memory fills (e.g. does not imply directly exercising external pins whatsoever). Having such call preventing you from using a USART is a bit surprising, except if having the DMA2D_Fill call the pins of the FSMC (the framebuffer is always located in the external SDRAM) and thus modifies your USART expected behavior, because they share those pins. However, using the regular Bitmap_Buffer's Put_Pixel should basically do the same (except that it's the CPU that's in charge of filling the framebuffer): e.g. exercising the FSMC. So your test is a bit puzzling.

BTW, I suppose you're using the STM32F429I-Disco, right? I don't think there's such thing as stm32f29-disco board...

from ada_drivers_library.

Yes, it's the F429I-Disco board I've been using. UART5 shares with DCMI, SDI and SPI I believe, neither of which I believe are used for this scenario. It's interesting because I had identical results with some of the other UARTs that I got working aside from 5 in that the behaviour seems to be that it's the receive side which fails. Unfortunately I can't get the debugger working on my board (GPS just hangs) - the simple test I did was to loopback the port then send a byte & call the (blocking) read to fetch it back. If I put this code before the call to initialise and clear the screen then the screen only gets cleared if the loopback cable is connected (as you'd expect - remove it and the character is never received). However if I put the serial code after the display initialise but before I clear down the screen, the screen is always cleared regardless of whether the loopback cable is connected or not. This suggests that it is simply falling through the test for receive data ready.

Rgs,

Jon.

from ada_drivers_library.

Just to make sure I understand properly the situation:

• you setup the pins for the UART
• you start communication: everything's fine
• you initialize the display
• communication stops as soon as DMA2D functions are called.

Are the steps correct?

What about initializing the display first, and then setup the pins?
Also have you tried to lock your pins after configuring them?

from ada_drivers_library.

Here is the relevant bit of code:

   Display.Initialize;
   Display.Initialize_Layer (1, RGB_565);
   Display.Set_Orientation (HAL.Framebuffer.Landscape);

   Initialize (COM);
   Configure (COM, Baud_Rate => 115_200);
   Outgoing.Set (HAL.Byte (65));
   Put (COM, Outgoing'Unchecked_Access);
   Get (COM,Incoming'Unchecked_Access,1) ;

   Clear;

so in this configuration, the UART configuration doesn't work. Moving the Initialize(COM) call to before the display initialisation code doesn't make any difference. Moving all the comms code to before the display initialisation sequence gives the expected result ie. the Get call only completes if the TX/Rx pins are looped back on each other. I haven't looked at locking the pins.

from ada_drivers_library.

At this point you have to inspect the state of the drivers with the debugger. Reproduce the erroneous state and try to search why the UART is not working. What is the failure exactly? Is the code waiting in a busy loop? If yes, what is it waiting for? Are the UART registers in a good shape? Is there any error flags in the status register? Etc.

from ada_drivers_library.

As I mentioned in an earlier post, so far I've been unable to get the debugger working with GPS2016 - I've installed it on 2 different machines and both of them just hang GPS when I launch it.

I've achieved what I intended with this board for now so this isn't really an issue for me any more, I was more pointing out what I'd discovered along the way. Happy to try things to assist with improving the software but I haven't got the time to devote significant amounts of effort pursuing it.

from ada_drivers_library.

A quick question: are you on linux or windows? In the first case, what version of stlink tools are you using? (c.f. https://github.com/texane/stlink). Also have you tried upgrading the stlink firmware on your board?

from ada_drivers_library.

it's on Windows and that;s a good point - I upgraded the firmware the other day for a different reason but haven't tried using the debugger since. I will give it a go when I get five minutes and report back.

from ada_drivers_library.

Sorry for the delay in getting back onto this, been a bit busy with other things. I'm using ST-LINK 3.9.0 and just tried a debug session with this version of firmware and unfortunately it's made no difference - GPS just hangs indefinitely when the session starts.

from ada_drivers_library.