STM32 Development

Tags: #<Tag:0x00007f13e777e410> #<Tag:0x00007f13e777e280>

(Paul) #143

Yes the Nucleo144 board is ~£6 dearer than the Nucleo-64, but it has more physical IO pins, a bigger PCB, a micro USB port and an Ethernet port (that I know about), the actual F303 chip is a negligible difference, which if/when this goes to production is what counts. There is currently no intention of using the Nucleo boards beyond development, they are just a dev tool.

I can’t answer the question about whether the code will run on both as I’m not sure what the code will consist of yet, but if it doesn’t, I do not expect it to take too much to change it. Generally speaking, as far as I can tell the code should/could be portable and could be compiled with the different board settings from the cubeMX, but if we’re addressing adc’s that don’t exist on the smaller board, that will still need changing I guess.

(Bill Thomson) #144

Admittedly a little late to the party, but I’m using Windows 7.
My Nucleo board arrived yesterday, so now I’m waiting for the shield.
In the meantime I’ll rig up a breadboard and a CT.

Following your lead, I installed gcc-arm-none-eabi-7-2017-q4-major.
Then, to get make, I installed Msys2 (a MinG-type environment)

The BINPATH fix worked like a champ.

First compile/flash went sans warnings/errors.

(Paul Reed) #145

Is that Msys2 Bill?


(Bill Thomson) #146

It is… Looks like I fat fingered the kybrd… :blush:

Tnx for catchin’ that!
(post corrected)

Just finished compiling dBC’s txshield_demo_4 w/o any problems.
Gettin’ there. A little at a time…

(Paul) #147

I didn’t actually pursue the windows path any further after finding make already wasn’t there, I now have the STM32 board plugged in to a Pi that I can access remotely, it means I can now work from the laptop in various places without dragging the stm32/shield/CT’s and AC adapter around.

(Bill Thomson) #148

That’s what I’ll do eventually. ATM, all my Pis are being used in various projects, so I need to get another.

In the meantime, I’ve set up 64-bit Debian Stretch on an Intel box.

Did you run into anything wonky when you installed CubeMX on your Pi?

Got it figured out. 64-bit Stretch needed 32-bit libraries. (sudo apt-get install ia32-libs)
Once those were installed, installation went OK.

(Paul) #149

No I didn’t install cubeMX to the Pi, it’s a utility that doesn’t actually connect to an STM32, so I still use that on my windows PC plus I don’t have a remote desktop set up on that Pi. With github you can work on the files from multiple machines.

Good to know if I do decide to go totally Pi :slight_smile:

(Paul Reed) #150

Strange, I’m using Debian 64bit, and didn’t need to install 32bit libraries.

(Paul) #151

Lifted from the STM32Cube user guide

"Linux®: 32-bit (x86) and 64-bit (x64) (tested on RedHat, Ubuntu and Fedora)
Since STM32CubeMX is a 32-bit application, some versions of Linux 64-bit
distributions require to install 32-bit compliant packages such as ia32-libs."

It also says

“Recommended minimum RAM: 2 Gbytes”

My i7 PC has 16gb and cubeMX isn’t exactly the fastest SW to open on that so I might not bother trying it on a Pi.

(Paul Reed) #152

Very ambiguous!

(Paul) #153

Sounds very much like a smartly worded “if it don’t work try this…”

(Paul Reed) #154

…my thoughts exactly :open_mouth:

(Bill Thomson) #155

Here’s a HiRes copy of the NUCLEO-F303RE pinout.

(dBC) #156

Do they even make an ARM binary of it?

That 32-bit shared library support for 32 bit applications on 64-bit kernels is a real mess. Every distro solves it differently. Whether or not you need to do anything may well depend on whether or not you (or your distro) have previously installed any other 32-bit applications. I can imagine it was a bridge too far for stm to fully package-ise that. Personally, I’m just grateful they built a Linux version, even if they have left it up to the user to sort out the library requirements. Had it been necessary to fire up a WIndows VM every time I needed to reconfigure the processor, I doubt I would have chosen stm32.

(Trystan Lea) #157

In our PM I noted my intention to complete the following set of challenges to further my learning for the STM32 platform:

  • Follow your tutorial @dBC and expand on my STM02 code to read the voltage on one ADC and the four emontx shield CT inputs on a second ADC.
  • Reproduce some of your ADC timing oscilloscope captures so that I can verify and understand the simultaneous sampling
  • Upload firmware without using STLink and understand basic requirements in terms of circuits design.
  • Test an onboard opamp based buffered bias.

I’ve made progress on the first two today :slight_smile:

First of all I am reading voltage on ADC1:PA0 and current on ADC2:PA4, which translates to the AC voltage input and CT2 on the emontx shield. I’ve extended the power monitoring math to include crossing detection so that the output readings relate to an integer number of half wavelengths. This is all standard EmonLib calculations - Im not trying to do anything clever, just trying to get sensible readings. I have uploaded the code here its worth noting that these ‘examples’ are more for my learning than anything.

Here’s a sample of results, showing a 3kW fan heater being turned on:

Vrms    Irms    RP      AP     PF       Samples per reading
238.80  0.10    2       23      0.104   13029
239.02  0.10    2       23      0.101   12948
239.24  0.10    3       23      0.114   13026
239.24  0.10    3       23      0.117   13029
239.45  0.10    3       23      0.109   13027
239.45  0.10    3       23      0.107   12948
237.72  5.81    772     1381    0.559   13027
234.04  12.40   2912    2903    1.003   13028
234.04  12.40   2911    2903    1.003   13028
234.69  12.45   2926    2922    1.001   12947
233.82  12.40   2907    2900    1.002   13027
233.82  12.40   2905    2900    1.002   13029
233.82  12.40   2901    2900    1.001   13028
234.69  12.40   2917    2911    1.002   12946
233.82  12.35   2896    2888    1.003   13028
233.82  12.35   2895    2888    1.002   13029
233.82  12.35   2894    2888    1.002   13028
234.47  12.40   2910    2908    1.001   12946
234.04  12.35   2898    2891    1.002   13029
234.04  12.35   2897    2891    1.002   13027
233.82  12.35   2896    2888    1.003   13028
234.04  12.35   2899    2891    1.003   12945
236.42  9.03    1734    2136    0.812   13028
239.45  0.39    5       94      0.057   13029
239.45  0.10    2       23      0.095   13029
239.02  0.10    2       23      0.106   12944
239.45  0.10    2       23      0.107   13029
239.45  0.10    3       23      0.131   13028
239.45  0.10    3       23      0.139   13028
238.80  0.10    3       23      0.144   12945
239.45  0.10    3       23      0.141   13030

Then I tried to replicate your scope captures @dBC by adding a 1M pull up on the ADC inputs with the shield removed which works great!, I was hoping the result would show simultaneously sampling but it looks like its still sequential:

I started digging into your shield example code and noticed timer 8 code which I think is how your triggering the ADC conversions? I tried to add this timer in but have not been able to make it to work yet…

small steps forward…

(dBC) #158

Yes, there’s a description of the approach I took above.

It looks like you’re ADCs are configured for “regular conversion launched by software”. That ~1.25usec lag you’re seeing is most likely how long it takes to call HAL_ADC_Start_DMA() so your two back-to-back calls aren’t quite simultaneous.

My .ioc file is included in the tar file, so if you crack that open with SMT32CubeMX you’ll see how I configured things so that the HAL_ADC_Start_DMA() calls just enable the ADCs, and then they all sit around waiting for the starter’s gun to fire (TIM8). Hopefully, when viewed with the link above in hand, it’ll all make sense but if you’re still stuck ask away.

(Trystan Lea) #159

Thanks @dBC, I’ve tried following your notes above and looking again more closely at your example code and still no luck. Here are the main changes to the code made: and the new includes

I simplified the start ADC’s function to

  HAL_ADC_Start_DMA(&hadc1, (uint32_t*)adc1_dma_buff, ADC_DMA_BUFFSIZE);
  HAL_ADC_Start_DMA(&hadc2, (uint32_t*)adc2_dma_buff, ADC_DMA_BUFFSIZE);

I think that’s what your code is doing? am I doing it correctly?

(dBC) #160

Yes, I can’t see anything obviously wrong. What are the current symptoms? Still a staggered start as shown on your scope trace above? Do you see a 1usec low pulse on PC7? And if so, when does the first ADC sample happen relative to that pulse?

(Trystan Lea) #161

Im not sure that its actually starting… or perhaps its completing the first sample and then not continuing? The LED stays on which suggests no conversions have taken place?

Test PM quotes
Test PM quotes
(dBC) #162

Yes, if you’re not getting any interrupts it sounds like the ADCs haven’t triggered. Can you see a pulse on PC7? If Yes, then we need to work out why the ADCs aren’t triggering on it, if No then we can look at the timer setup.

Can you post your .ioc file as well please?