开云体育

Has anyone though of upgrading the STM32F072C8T6 to other MCU with larger SRAM and flash memory? The original NanoVNA author, ttrftech, uses STM32F303 for his other project CentSDR and has the chip data defined at



From the datasheet, it seems that STM32F303CCT6 is a good replacement for the original STM32F072C8T6. 256KB flash memory versus 64KB; 40KB SRAM versus 16KB. This enables the possibility of enlarge the sample points from 101 to more points, and other features.

Before I start rework on th LQFP-48 IC for the first time in my life, I would appreciate your feedback on the feasibility and suggestions.

Ken

Hi Ken,

I have thought about it, and am used to LQFP transplants. Have you double
checked the pin assignements ? Sometimes ST does subtle changes between
series (BTW I think they did to much changes going to the STM32G4 series,
but if someone does a new version of the PCB a compatibility would be
nice). As for LQFP rework, I never burned an STM doing it, tell me if you
need more info on the process.
On the software side, it seems that the original author has used Chibios
which has some level of abstraction and supports the F303. The usual
difficulty with the STM32s is to get the clocks properly initialized, and
this is likely different between the 2 MCUs, you should be confortable with
reflashing the firmware (a lot), first make a led blinking program with the
F0 and then the F303, also I would get a Nucleo F303 to get acquainted to
the series.
It is unfortunate but I can't commit to actively participate to this
project for the next few month, but I may be able to help here an there by
email.

Best
Jose

Is this a pin compatible alternative? If it is, I'm ordering a 2nd unit from China. And will be doing LQFP rework for the first time also. I had looked for a pin compatible device myself, but got rather lost in ST's product selector.

I did some calculations this morning and there is not enough RAM to add TDR to the existing FW.. But an extra 24 KB would do the trick. It may be possible to get a 1 microsecond time window and 100-125 ps time resolution with the more powerful chip.

However, an alternate FW which just did TDR could provide 1 microsecond and 200-250 ps resolution on the current chip. That would be very useful in a portable device. And at $35 cheap enough for only occasional use.

Have Fun!
Reg

For more flash memory, the STM32F072CBT6
( note: CB instead of C8 ) has 128k flash instead of 64k and will work
without hassles. I have heard that sometimes the C8s where actually CBs,
therefore you may just try your luck flashing a bigger firmware before
attempting surgery.

Ref: page 124 of the datasheet


Jose



On Mon, Sep 2, 2019, 17:41 Reginald Beardsley via Groups.Io <pulaskite=
[email protected]> wrote:

Is this a pin compatible alternative? If it is, I'm ordering a 2nd unit
from China. And will be doing LQFP rework for the first time also. I had
looked for a pin compatible device myself, but got rather lost in ST's
product selector.

I did some calculations this morning and there is not enough RAM to add
TDR to the existing FW.. But an extra 24 KB would do the trick. It may be
possible to get a 1 microsecond time window and 100-125 ps time resolution
with the more powerful chip.

However, an alternate FW which just did TDR could provide 1 microsecond
and 200-250 ps resolution on the current chip. That would be very useful
in a portable device. And at $35 cheap enough for only occasional use.

Have Fun!
Reg

Might hold the STM32F on the nanoVNA in reset, should tristate all of it's IO pins.
Wire a new connector to the board to give access to the i2c bus and the A2D's
serialized data, also that STM32F reset pin so it can be easily grounded.
Cable that connector over to a Raspberry Pi.
Port the nanoVNA's STM32F embedded software to the RPi.
/g/nanovna-users/message/1453

Can now have a 27" 1920x1080 HDMI screen, or perhaps a small 5" at 800x400 for portable use.

Can easily add switches and quadrature encoders into the RPi if a mouse is too much trouble.
Compile and run all the STM32F nanoVNA embedded software and any experimental extensions
as one big happy program on the RPi.
Have gigabytes of RAM available for correction factors and plot points and such.
Could still disconnect the RPi from that new connector and go back to a stock nanoVNA,

Jerry, KE7ER

What a great idea. The RPI zero wireless is $10 from Adafruit and would be more than powerful enough for this task - and it's got WiFi and usb host mode to boot!

One could always use the serial port to control the nano via the console commands.

I would expect that the speed could be raised to 115200 baud from the 9600 baud default. It might require disabling the display, but if you're adding a larger display on the Pi Zero it doesn't matter.

In any case, the scripting language of your choice and gnuplot will produce very nice figures.

On Mon, Sep 2, 2019 at 11:41 PM, Reginald Beardsley wrote:

Is this a pin compatible alternative? If it is, I'm ordering a 2nd unit from
China. And will be doing LQFP rework for the first time also. I had looked
for a pin compatible device myself, but got rather lost in ST's product
selector.

I did some calculations this morning and there is not enough RAM to add TDR to
the existing FW.. But an extra 24 KB would do the trick. It may be possible
to get a 1 microsecond time window and 100-125 ps time resolution with the
more powerful chip.

However, an alternate FW which just did TDR could provide 1 microsecond and
200-250 ps resolution on the current chip. That would be very useful in a
portable device. And at $35 cheap enough for only occasional use.

Have Fun!
Reg

If you need it, I can send you a NanoVNA with the STM32F303CCT6 installed.

hugen

Hi Reginald,
in my experience, you can run the serial port at whatever speed you desire
(within reason, I'm sure) - it is a USB serial port, and I'm happily
running it at 115200 in my software with few problems. There is the
occasional single-bit/byte transmission error, but I think that's purely
from the large number of bytes sent. (If anyone has other suggestions, let
me know - it's a TODO on the list).

TLDR: The USB driver negotiates the speed, higher speeds are fine.

--
Rune / 5Q5R

On Wed, 4 Sep 2019 at 01:26, Reginald Beardsley via Groups.Io <pulaskite=
[email protected]> wrote:

One could always use the serial port to control the nano via the console
commands.

I would expect that the speed could be raised to 115200 baud from the 9600
baud default. It might require disabling the display, but if you're adding
a larger display on the Pi Zero it doesn't matter.

In any case, the scripting language of your choice and gnuplot will
produce very nice figures.

I don't know if the STM32F303 is pin-compatible with the existing chip, but
I did check earlier that STM32F104 should be a direct drop-in, and offers
slightly more RAM (20kB) and 128kB of flash memory at the max spec.

If cost is a concern, this may also be slightly cheaper.

--
Rune / 5Q5R

I have verified the pin assignments for the STM32F072 vs the STM32F303 for the LQFP-48 package from the ST datasheets. Unless I made a mistake they match exactly. I was very careful, but it would be nice if someone else checked also.

I read the assignments off the schematic and then checked them against the datasheet for the STM32F303 part.

The STM32F303CCT6 shows from Digikey at $4.37 quantity 100 vs $2.62 for the current part quantity 100 price. For 2400 it is $3.20 vs $1.92 so a $1.28 uptick in cost in production quantities.

I'm going to take hugen up on his offer to provide a unit with the STM32F303CCT6 part installed. Having triple the RAM and twice the flash should make it possible to add a lot of interesting features.

Units without the LCD and with provision for control via the USB port would be fantastic with a Pi Zero.

Have Fun!
Reg

BTW I did verify that the port auto-negotiates the speed and am able to connect to the console at 115200.

I have successfully ported the NanoVNA firmware to support STM32F303CCT6. The detail can be found at



The minimum required hardware mod is to replace the MCU and add a 1.5K ohm resistor between USB_DP and VDD, or between USB_DP and PA10.

If you have the chance to try the code, please let me know if you see any issue.

Ken

Fantastic!!!
This opens up the possibility of a whole new round of firmware-based functional enhancements for this device.
Thanks for the effort.
It would be great if you could upload a few photos of the mod to the Hacks and Mods folder in the Files area and maybe give some info on where you obtained the replacement uP from and price.

Regards,Larry

On Wed, Sep 4, 2019 at 08:35 AM, Rune Broberg wrote:

it is a USB serial port, and I'm happily
running it at 115200 in my software with few problems. There is the
occasional single-bit/byte transmission error
TLDR: The USB driver negotiates the speed, higher speeds are fine.

The speed which you set for NanoVNA COM port doesn't matter. The speed value is just not used. No matter what speed you choose, it always communication at maximum speed. :)

If you have trouble with occasional transmission error. Try this firmware, it should solve your issue:

It also has scanraw command, it allows to perform measurement for unlimited amount of points, and with using average up to 1000x. But it returns raw measured values, with no calibration apply. So, you're needs to apply your own calibration to the result.

For example this command will return you S11 measurement (with no calibration apply) from 50 kHz to 10.050 MHz with 1 kHz step (10000 points) and with 5x average:

scanraw 0 50000 1000 10000 5

where
0 - channel CH0
50000 - start frequency
1000 - frequency step
10000 - needed point count
5 - average times

On Wed, Sep 4, 2019 at 08:39 AM, Rune Broberg wrote:

I did check earlier that STM32F104 should be a direct drop-in, and offers
slightly more RAM (20kB) and 128kB of flash memory at the max spec.

NanoVNA already uses STM32F072CB which has 128 kB flash and 16 kB RAM.
NanoVNA uses end of 128 kB flash block to store configuration and calibration data.
So, if your NanoVNA can store and restore calibration, it already has 128 kB flash. :)

Nice enhancement.I'll add this to my Console command document, specifying your version of firmware.
Regards,Larry

Somehow my photo of NanoVNA with STM32F303CCT6 and the USB mod uploaded to "files/Hardward Mods" didn't show up there. So I attached my photo below. The PCB was provided by Hugen, since I don't have steady hands to solder such tiny wire and component myself.

A 1.5K reistor was soldered between pin PA12(USB_DP) and VDD so that host PC can recognize the NanoVNA for serial comminication. The C6 decap nearby has a VDD pad near MCU. The PCB is full of flux because Hugen reworked it to replace the MCU to F303, and I did it again to clean up the solder bridge underneath the MCU.

I reaplced the STM32F103C8T6 on a Bluepill board with STM32F303CCT6 for initial porting, before receiving the NanoVNA PCB from Hugen. For debugging, I use ChibiStudio, OpenOCD,
and a Nucleo board as ST-Link v2. Becasue DFU doesn't work at F303 yet, I have to use ST-Link to burn firmware, instead of USB DFU. Maybe a bootloader is needed for F303, like m0nka's mchf SDR transceiver.

For larger LCD, I tried a 3.5" 480x320 LCD with ili9488 controller on my F303 Bluepill. I was able to port to ili9488. But since ili9488 doesn't support RGB656 as ili9341 does, each pixel needs 3 bytes to trasnfer RGB666 or RGB888. And since STM32 doesn't support SPI with 24-bit data, each pixel takes three times of one byte transfer; while ili9341 just neesd to transmit 16-bit data at one time. Besides, the 3.5" LCD has twice the pixels to draw than the original 2.8" 320x240 LCD. Even after some optimization, the result is still dismal. It seems that ili9486, which supports 16-bit per pixel over SPI, would be a better solution than ili9488.

With larger LCD and SRAM, I was hoping to increase the number of sweep points from 101 to 201. Athough I was able to double the sweep points, I could not save the calibration result. Each time I save the calibrated data, it hangs. I think I need to look into the flash.c code.

Ken

On Sun, Oct 20, 2019 at 04:35 PM, Ken Liao, AA6KL wrote:

Athough I was able to double the sweep points, I could not save the
calibration result. Each time I save the calibrated data, it hangs. I think I
need to look into the flash.c code.

NanoVNA firmware uses poorly hardcoded memory address in the flash for store configuration. There is no check and it may overlap with the code. You're needs to check that.

Ken Liao, AA6KL wrote: I have successfully ported the NanoVNA firmware to support STM32F303CCT6.

Since adding firmware features to the present design is limited by the 128k/16k memory, are there any suppliers offering the NanoVNA produced with the 256k/32k memory devices? That would seem to be the logical evolution for this product.