2022-05-17 11:34 AM
I started from the documentation of both discovery board and MB1280-B1 STMOD board.
They both state, that the pin number 2 of STMOD+ (P2) connector of the discovery board is connected, I quote: "SPI2_MOSI/ USART2_TX (PC3/PD5)".
So - USART2, pin PD5. That's what I set in CubeIDE.
I configured the USART2 as Single Wire Half Duplex, because I connected DS18B20 temperature sensor using Single Wire protocol.
My setup was tested with an other Nucleo board and it worked. Tested with drivers and all.
The problem is - despite the USART2 initializes properly, it doesn't read anything. To be exact - I get 0x00 instead of 0xe0 that is expected.
It behaves as nothing was connected to the USART2 TX pin.
Then I changed my target port to USART6, that is by default assigned to PC6 pin. It is also accessible on STMOD+ connector, as INT signal. I don't like it, because I was planning to use that pin for a different purpose.
But anyways - it works. So my code is correct, my connections are OK, my DS18B20 is operational and reads the correct temperature.
The problem is I can't use USART2 as is described in documentation. There is a "USART2 TX" pin described in my discovery board documentation. It should be PB5 MCU pin. That's what I have set in IOC file. But somehow - it doesn't work.
I suspect the problem here is it's not only USART2_TX (PD5), but also SPI2_MOSI (PC3). It's like "SPI2_MOSI/ USART2_TX (PC3/PD5)" entry in the table. So... which one? Is it somehow selectable?
Also, when I want to use SPI2 - it's also pin nr 8 of the STMOD+, described as " SPI2_MOSIs (PB15)"... I'm a little lost here. I thought SPI needs just MOSI, MISO, NSS and SCK. What's "MOSIs"?
Is it possible to use both SPI2, USART2 and I2C4? I'd also need an interrupt input (from GPIO expander), one PWM input and 2 PWM outputs. All applicable pins seem to be accessible looking at the documentation and IOC configuration, however - it doesn't work as I think it should work. What am I missing here?
UPDATE: I also read Appendix B on page 59 of the STM32H747I-DISCO manual, it's super confusing. The same pins are bound to RX, TX, MISO and MOSI signals. So - pins 2 and 3 can be TXS2 and RXS2, or RXS2 and TXS2, depending on which table column you read. But - as I tested - neither works. I try to read USART2 on PD5, I get nothing regardless of the signal connected to the STMOD+ pin 2 or 3. When I connect the signal to pin 11 of STMOD+, I can read it as USART6 PC6. Why, why and why?
2022-05-17 01:16 PM
It appears from the board schematic that PB5 is not connected to the PMOD connector by default.
You need to connect SB33 ["solder bridge 33"]. You may also want to remove SB34 or ensure that PC3 is configured as an input.
2022-05-17 02:07 PM
Trick here is to go directly to the schematic, these are usually pretty solid with respect to what's delivered and what jumper/bridge defaults are.
2022-12-11 06:20 PM
Hi HTD,
I've met the same problem on the STM32H747 Disco board. How do you solve this problem?
2022-12-11 08:38 PM
Most discovery boards use high pin count package, and not enough pins to do all external signal connexions, it is in pin starvation with many built-in companion chips, screens, audio, etc... stmod+ is exporting typical signals onto 16 signals with fixed pinout, so it covers PMOD, GROOVE, CLICk and hw handshaked UART. Usart xor spi uses same 4 pins, however the alternate functions don't natively support spi xor usart. I have seen some solder bridge to mux signals, external active mux controlled by io, or shared signals between stmod+ and arduino or camera interface. To have pins for further customisation and reuse by end users is quite a challenge... Clive is right, schematics is more important than board user manual to read first. Making discovery more than a monolithic block is definitely challenging I guess...
2022-12-12 01:24 AM
By moving the solder bridges.
2022-12-12 01:39 AM
Using another discovery board I learned to start from the board schematics. I think it's a kind of an exercise in exploring how it's built and how it works. Then designing an own board with the same chip and similar peripherals will be easier, as you've already seen how it was done many times. Oh - it's quite a PITA how the VBAT is connected. If you want to use a battery then you have to solder wires directly to the board. No connector provided at all. After some time I find the biggest challenge is the software, not the hardware. I mean - the examples. Like ST leveraged using of EWARM instead of their own STM32CubeIDE. When you're a new kid on the block the IDE is a way to go, the hardware configuration manager and HAL allow you to just test most of the features immediately. With TouchGFX you just start from making GUI, not struggling with LCD to display a pixel first. People here use to bash the HAL on this forum, probably mostly because of code quality, aka bugs ;) Still, I think it was well worth it to start from HAL. I only wished the examples provided with Discovery boards could be run or tested with the environment provided by ST. BTW, there are 2 incompatible APIs used in examples: BSP and HAL. Not very helpful for the people looking for to get started quickly. The code can be refactored very straightforward, but the first time I was doing that it was not obvious at all and took me some time to learn.