|
Forum Index : Microcontroller and PC projects : SPI3 on ARMmite H7 problems
| Author | Message | ||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
I am having problems with getting SPI3 to work. I am using version 5.0506 on the STM32H743ZI on my own custom built board, not the Nucleo Development board. SPI1, SPI2 and the LCDscreen all work correctly. My SPI device works fine on the PIC32MX chip using the same 1Mz clock speed, but when connected to SPI3 of STM32H743ZI chip it does not work. Is PIN48 for MOSI correct for SPI3? I tried using PIN135 PB5 SPI_B_MOSI instead of PIN48 PB2 as it is the arduino connector pin for MOSI for this SPI, but that made no difference. Why was this changed to PIN48?? Could the SWO used during programming affect the SCLK for SPI3 as they share the same PIN133. I obviously don't have the STLINK board attached as I only connect it for loading the firmware. I would presume that SPI3 has been tested ?? Any ideas?? Has anyone been using SPI3 successfully?? Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
Please try the attached. Looks like some config got overwritten at some time in the past 2019-06-16_180234_Armmite1.3bin.zip 2019-06-16_180259_Armmite1.3hex.zip Note this version has some biggish changes to optimisation and SDcard handling (faster) so please report any issues |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1945 |
FYI: Just tried the posted bin file. Program errors with two invalid pin numbers. Error: Pin 112 is invalid (PC11) Comment out above, then Error: Pin 99 is invalid (PC9) Comment out and rest of program runs although other Pin errors can't be checked until I connect up the hardware interface. Works correctly with previous Bin file. NANO Inverter: Full download - Only Hex Ver 8.1Ks |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
Sorry: I'm in the middle of some changes but hopefully this version corrects that 2019-06-16_194636_Armmite1.3bin.zip 2019-06-16_194651_Armmite1.3hex.zip |
||||
| KeepIS Guru Joined: 13/10/2014 Location: AustraliaPosts: 1945 |
Thank you all good now. FYI: I'm using every pin on the two inner rows of pins on the H7 and obviously the LCD on the reserved LCD, SD and console pins on the outer rows, everything look good now. Mike. NANO Inverter: Full download - Only Hex Ver 8.1Ks |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
Sorry to be a pest, but I am still having trouble with SPI3 after flashing with 2019-06-16_194651_Armmite1.3hex.zip Can someone please test it to ensure it is working. I am using PIN133 - SCLK, PIN48 - MOSI, PIN134 - MISO as per the documentation and selected PIN132 for CS. As stated I can use the same SPI device using the same code (detects the different processor and changes the PIN assignment) on the PIC32MZ and it works fine. Thanks John Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
The code posted above definitely works but there is a "funny" with the STM implementation which may be affecting you. Both the data and clock lines seem to go tri-state off when not in use and the clock voltage will drift down towards 0. If you are using mode 2 or mode 3 then it may be worth trying a 10K pullup on the clock line ![]() The attached version sets a pullup internally when mode 2 or 3 is selected 2019-06-22_193408_Armmite1.3bin.zip 2019-06-22_193425_Armmite1.3hex.zip |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
All my SPI peripherals use the common MODE 0 format. I get the same results even when dropping the clock rate down to 10 kHz, so it does not appear to be related to clocking or data signal degradation. It appears to have no data on the MOSI from the STM32, I think?? I will have to take the DSO home from work and have a look. Thankyou for looking into this for me. Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
SPI3 MOSI pin appears on PIN135 when running 5.0506 not PIN48 and works but with errors. Digital lines look fine on DSO I think with MOSI pulled high by STM32. Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
Good news got SPI3 working but only with ver 5.0506 and no errors using PIN135 for the MOSI. Version 5.0507 does not work with MOSI on PIN48 or PIN135 Can you correct ver 5.0507 so that MOSI is PIN135 as with the previous version as we know this works fine. thanks Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
MOSI on SPI3 definitely works properly on pin 48 in 5.05.07. You must have a dead pin/or connection. The backpack PCB is wired for pin 48 so I don't want to change that. It was a temporary error when it was set to pin 135. The trace below is from my development Nucleo and backpack with the binary above and MOSI tied to MISO SPI3 OPEN 1000000,0,8 ? SPI3(123) ![]() |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
I think I have worked out what is wrong with your 5.0507 firmware for SPI3. It only clocks 8 bits when a 16 bit write is requested. Here is the SCK(green) and PIN48 MOSI(yellow) for a 16 bit write ver 5.0507 ![]() Here is the SCK(green) and PIN135 MOSI(yellow) for a 16 bit write ver 5.0506 ![]() Your SPI3 firmware for 5.0507 has a problem with accepting a 16 bit write. thanks John Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
Now if you had said that before..... See the main thread for fixed version |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
I hope you are just joking? If not, Maybe you should consider giving back, just a tiny bit of the appreciation showered on you, to those who first assume its their own mistake and then spend all their weekend finding the problem in your Micromite firmware and thus helping you to fix it for all of us. Keep up the great work! John Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10572 |
The point I was making is that when debugging the more information about the problem given the easier it is to diagnose. Throughout this thread we have been working towards the solution. First the error with the pin, then the issue I found with modes 2 and 3 and the clock going tri-state. To try and solve it I repeatedly set up my scope and tested to make sure each version I posted was working. The bit I was missing, and which I didn't test, is that you were using a 16-bit transfer. If you had mentioned this or posted your SPI3 OPEN statement, I would have seen that and tested exactly the command you were using which would immediately have found the problem. I try and make sure, not always successfully I know, that code works before I post it. However, it is impossible to test every variant and in this case a single line of code in a big cut-paste-modify was incorrect. That line dealt with transfers other than 8-bit which is the default used in 99% of cases. The bug was introduced as part of the numerous conditional compilations needed to support the Armmite F4 and nothing to do with the pin number change so I knew that going back to pin 135, as you suggested, wouldn't have solved the issue and hence my assumption that you had a hardware issue as the implication of your posts was that you weren't getting anything on MOSI. Anyway, it is now fixed. I'm sorry it has taken so long but I needed the key bit of information about the 16-bit transfer to find the problem and you wouldn't have needed to spend so much time on it had I known that. We live and learn |
||||
| HardingJohn Regular Member Joined: 28/07/2017 Location: AustraliaPosts: 78 |
The funny thing is that I had tried to post my SPI code but the Backshed Server was down. The good news is that I bought my own USB Scope instead of having to borrow the DSO from work. Bloody marvellous. This Armmite MMbasic creation has got to be the best thing since sliced bread. My point was that everyone deserves a little bit of appreciation for helping you make this such an incredible sliced bread, even if we are only helping to find the crumby bits. Thankyou again for all your hard work. John Just know enough to get me in trouble, but not quite enough to get me out. |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |