RESC: Automotive quality high voltage fork from the VESC

Discuss hardware related to the VESC such as the NRF nunchuk.
rew
Posts: 937
Joined: 25 Mar 2016, 12:29
Location: Delft, Netherlands.

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby rew » 07 Jun 2017, 15:43

So with the 144 pins you should be able to upgrade to F7. Personally I would expect that you'd stay at the F4 once you have that running, but it could be an interesting exercise to upgrade to F7.

ragonamuffin
Posts: 37
Joined: 04 Apr 2017, 02:08
Location: CT, USA

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby ragonamuffin » 07 Jun 2017, 16:39

I will probably stick with the F4 for the first two that I build, I will then move to the F7 with the same dev board since I can just interchange these processors, right?

ragonamuffin
Posts: 37
Joined: 04 Apr 2017, 02:08
Location: CT, USA

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby ragonamuffin » 07 Jun 2017, 17:03

I can also send you a board if you want to mess with it when I'm done

ragonamuffin
Posts: 37
Joined: 04 Apr 2017, 02:08
Location: CT, USA

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby ragonamuffin » 07 Jun 2017, 17:14

Compatibility: Cortex-M7 is backwards compatible with the Cortex-M4 instruction set


This is from ST's site: http://www.st.com/content/st_com/en/pro ... tId=SS1858

Why does it say this? This is what made me believe I could just slap in a new processor, match up the labeled pins, and be done with it.

rew
Posts: 937
Joined: 25 Mar 2016, 12:29
Location: Delft, Netherlands.

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby rew » 08 Jun 2017, 05:53

Did you see:
* Note: see datasheet for the specific case of 64- and 100-pin packages

(IIRC, the F7 doesn't exist in 64-pin and the 100pin version has the flaw we discussed.... ).

In theory you can simply plug in the F7. It's just that when things don't work first time around, it is much easier to debug when there are less variables.

If you use more than a few STM32 processors, you notice that their peripherals grow better as the processors are released over time. So for example, the STM32F405 has USB. And to use USB, you NEED to have a crystal. The much cheaper, but more modern F072 has "crystalless USB". In some applications that added feature might be nice on the F7. The processor is much more expensive, so just adding the crystal is possible. But it is also possible that some clients are going to appreciate the crystalless USB. So if you're having chips made, why not just add the feature? (This is a fictional example. I haven't checked the datasheets if they indeed added this feature!)

So now we have the F7, mostly compatible, but a few extra bits in some registers to enable the features that the F7 has, but the F4 does not. The datasheet is explicit in that reserved bits are "leave at reset value". This allows ST to add new features where compatibility with the older generation happens with a default-high bit in a control register.

But a "bug" in a program is really easy to have when there is no feedback that anything is wrong. And I would consider it a bug if a "reserved bit" is written to "0" when the manual states "leave at reset value". That kind of bugs will make porting the software difficult.
I HAVE found such bugs in ChibiOS. The maintainers are NOT interested in fixing them.

The hardware guys know this and design most of the used-to-be-reserved bits with the default value at 0.

Having a non-zero default value causes bugs. For example, you can tune the internal RC clock in steps of 0.5% from about -8% to +8%. 32 values, a 5 bit register field. Now by default you want to tune the RC clock in the middle. So the register runs from 00000 -8% .... 10000 0% .... to 11111 +7.5%. When you use the system bootloader to download your code, and then finish with a "jump-to-application", the bootloader clears this register in an attempt to restore the just-after-reset value.

So that's when you notice that your program runs on the internal RC at -8%, way out of spec (+/- 1%) .....

As far as I know the F7 bootloader will still have this bug...... even if I reported this years ago.

ragonamuffin
Posts: 37
Joined: 04 Apr 2017, 02:08
Location: CT, USA

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby ragonamuffin » 08 Jun 2017, 19:05

I'm going to have to re-read that many times to understand what any of that meant :lol:

I knew about the pinout issue going into the project with the smaller chips. they have a whole page about it on the datasheet.

I'm hoping that with the 144 pin I will not have to move around any pins at all! :)

Another EE project for a client is consuming most of my time right now. I will have more time soon.

rew
Posts: 937
Joined: 25 Mar 2016, 12:29
Location: Delft, Netherlands.

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby rew » 09 Jun 2017, 20:12

For the F4, it is the DOWNWARD compatibility that requires a few pages in the datasheet. What it boils down to is that you design your board for the F4, and you end up with two zero-ohm resistors (when you mount an F072 or the likes) where 2.2uF would have gone if you had mounted a '405. I use a solder blob instead of the zero-ohm resistor. Or when I know the board will have mostly 072 installed, I short the spot for the cap in the board design.

ragonamuffin
Posts: 37
Joined: 04 Apr 2017, 02:08
Location: CT, USA

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby ragonamuffin » 17 Jun 2017, 00:36

I am getting back to this project in the next few days I hope. I will post newer schematic soon!

ragonamuffin
Posts: 37
Joined: 04 Apr 2017, 02:08
Location: CT, USA

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby ragonamuffin » 25 Jun 2017, 23:27

What should I do about DC_CAL from the STM? Can I ignore this pin?
From the DRV datasheet:
When DC_CAL is high, device shorts inputs of shunt amplifiers and disconnects loads. DC offset
calibration can be done through external microcontroller.

rew
Posts: 937
Joined: 25 Mar 2016, 12:29
Location: Delft, Netherlands.

Re: Moving around pins on the STM32 and upgrading to f7 over f4

Postby rew » 26 Jun 2017, 08:50

You are not using a DRV83xx driver chip? I don't have it connected. As far as I know, the VESC will make sure no current is running and then do the DC calibration, without the use of the DC_CAL pin.


Return to “Related Hardware”

Who is online

Users browsing this forum: No registered users and 1 guest