Comments (11)
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.
Related Issues (20)
- Some examples do not build HOT 6
- Support LSM303AGR for newer micro:bit hardware revisions HOT 1
- Target not found for Micro:Bit with Debian Linux HOT 3
- Project Wizard doesn't generate startup files HOT 3
- Include directions in examples/README.md to have compatible versions of bb-runtimes and compiler
- Support for Adafruit Feather M0 board HOT 3
- mma8653 initialization fails on MicroBit HOT 21
- EXAMPLES: Installing run-time dependencies fails with both Python 2 and Python 3 on Linux HOT 2
- Make HAL packages preelaborable HOT 1
- I2C HAL ideas HOT 15
- Many warnings with GCC 12 HOT 2
- RISC-V requires "zicsr" ISA extension to build with FSF GNAT 12.1.1 HOT 11
- IO expander MCP23x08 reports GPIO mode always as Output HOT 1
- Support for STM32F411CEU6 board HOT 1
- Extension zicsr required in HiFive1_rev_B board
- Microbit.Time resets the board
- How to get the toolchain up and running? HOT 15
- Compiler crash with pragma Ada_2022 on body HOT 2
- gnatprove incompatibility
- Incorrect usage of 'Val instead of 'Enum_Val HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ada_drivers_library.