Netduino 2 Plus

I would start with the question: “How to flash the board?”
I see a mini JTAG header, but I guess nobody has experience flashing a board via JTAG (I suspect these pins are not equal with the ST-link ones or can be remapped for it) . So two possibilities:
ST-Link: Are all needed pins available?
Serial: Maybe the easiest way?

Stlink only needs 2 pins

Clock and data

Even if they are remapped, put boot0 high and stlink should work

Or black magic probe. See rick for a bmp binary

Hi folks !
Just to let you know : I found that Netduino2Plus is supported by MicroPython. So, I gave it a try, compiled, flashed it with dfu-util, rebooted, and I got the prompt over the USB Serial. :P

Micro Python on 2015-05-14; NetduinoPlus2 with STM32F405RG
Type “help()” for more information.
>>> pyb.LED(1).toggle()
>>> pyb.LED(2).toggle()

So, I’m pretty sure that stm32duino too can work if the STM32F405 becomes supported !

EDIT : I found this link https://code.google.com/p/libmaple-f405/, so that’s mean it is doable.

@martinayotte

You could just try the current F4 version

It works on the F407 as Mubase is using it.

Note. Its from an older branch of LibMaple so uses the older Arduino 0022 API, e.g doesnt have Serial.peek or Stream etc etc

But it does work

I really wish I had more time to update the F4 stuff to the level of the F103 but I just dont at the moment as there is so much still to do on the F103

I have been thinking about how we can merge the codebase, for F1 and F4 but yet still have different files.

The problem is that the Arduino IDE just compiles and links all files it finds in the cores folder

So we’d need to move the processor specific files from being in C files to having the code in headers

and then do conditional includes back onto the original files

e.g.

gpio_f1.c would need to be renamed to gpio_f1_c.h and a new file gpio.c created, that includes gpio_f1_c.h (or gpio_f4_c.h) etc

The other complication is that some includes are taken from the system folder and some aren’t

Actually, if we put gpio_f1_c.h into the system folder and have sufolders under system for f1 and f4, we would not need to do conditional includes in gpio.c as it could just have

#include “gpio_c.h” and it we could change the compiler include paths in the baords.txt file

This would need a change to boards.txt and platform.txt, but I think is something that could be done iteratively, i.e file by file, rather than trying to change the whole lot in one go and breaking it totally

I know ultimately we’d be better off with switching to STM’s headers, but I think that would be a much bigger job than just trying to merge the F1 and F4

I can only see 13 files in the F1 repo that have _f1 in their file name

Umm

Now I look at it.

They have done things a different way, but its less efficient,

in the F4 folder they have files with #ifdef STM32F2 around all the code

This is will work, but it means the compiler will be compiling at least 12 empty files each time, so will slow the build down a bit

I think the include method via different include paths specified to in platform.txt is probably the most efficient

Edit.
Not sure why they did this

But its the F2 files in the F4 repo that will be used as in boards.txt it defines

-DSTM32F2

Thanks, Roger !
I will give it a try when I get chance (I have trouble too to find time doing everything I wish )

Just to give update here about my Netduino2Plus experiments …

As you maybe saw, I got success doing a sketch on STM32Stamp board with STM32duino IDE, viewtopic.php?f=39&t=118#p1513.
During recent days, I’ve try the same on my Netduino2Plus, but didn’t get any success.
I think it doesn’t even reach the setup(). Even for Blink example.
It is a bit strange since both boards using the same F405. I will have to add some debugging code to find out… :shock:

At least, I’ve got the Netduino2Plus working with almost the same code I had for STM32Stamp before using STM32duino, based on the STM32F4xx_DSP_StdPeriph_Lib_V1.4.0, blinking LEDs and serving a USB Serial connection.

I’m not sure if the F405 uses the same initialization code and vector tables etc as the F407 (which works)

It could be you’d need to make a new variant folder for the F405 if it has less features than the F407

This is an area of the code I’m not that familiar with. On the F103 all the processors seem to be fairly similar and there is only one isrs.s file for all of them.

But my understanding of the F3 and the F4 is that the series is far more fragmented than the F103 series.

If you have the time, its probably worth downloading the STM32Cube (from STM’s site) and create 2 different projects, one for the F407 and one for the F405 and look at the files it exports.

Specifically in terms of vector tables and startup code

I think Rick Kimball has a bit more of a handle on this stuff, so you could try PM’ing him in case he has an ideas

Hi Roger,
Since the same sketch is running fine on my STM32Stamp board, which has the same F405, I don’t think the problem is in initialization code by itself.
I think it hangs probably due to hardware around it making an unwanted interrupt handler been called.
When I get chance, I will add some debug trace via a serial port in the initialization code, hoping to figure out which hardware function is causing the hang.

I was looking to the schematic of Netduino2Plus to find out which hardware can be the problem, because even adding debug trace thru Serial didn’t work.

And I’ve suddenly faced with the problem and jumped to the conclusion :
Quite simple, the external oscillator isn’t 8MHz but 25MHz (because it shared with Ethernet PHY) !
That’s why the CPU was freezing right at startup even before setup(), the PLL was producing an overclock by more than 3x 168MHz (525 MHz).

So, I look at the code and figure out how to tweak the SetupClock168() with a #define. After recompile the sketch, every things start working properly, GPIO, Serial1 as well as SerialUSB ! :P

My next challenge : trying to use Vassilis’s EtherCard_STM library, since Netduino2Plus has one ENC28J60 onboard !

Edit : @Roger, I’ve sent you a PullRequest for the changes…

Thanks Martin

Will the changes effect other boards or is it via a #define for your board?

Hi Roger,

I added it using the #ifdef ARDUINO_STM32F4_NETDUINO2PLUS, since this define was already generated by the boards/platforms mecanism.

You will also notice that I added a possible fifth argument to maple_upload, if provided, it will add “–dfuse-address” to the call to dfu-util.
This should not affect others too. (BTW, I added this because my dfu-util complains that the binary is not a *.dfu file, raw files seems to require this dfuse-address.)

Martin

Ok. About the #define

Normally with the f103 I’m not keen on putting board specific stuff in the core, and I’d probably try to do this via a new variant.

But as the F4 stuff is basically an experimental spinoff, I think its ok for now, and we can sort it out when and if I ever merge the F4 and F1 code bases.

I will check it still works on my F407

Re DFU

Ok. I didn’t even know it can upload via DFU, I thought it was only stlink

Or did you add this.

Anyway

No worries

Hi again Roger,
In fact, your F407 will still has the 8MHz value, only Netduino will get the 25Mhz.
During Merge or Refactoring, maybe it is a good idea to have some kind “board.ext_osc=25” or “board.ext_osc=8”, but for now, I think the #ifdef is simplier. I’ve look to my F429 board, and it is also a 8MHz. So, I presume that the only boards with different oscillators are the one sharing it with PHY.

About DFU, since I didn’t have my new ST-Link yet, I didn’t have much choice for uploads, even with my maple-mini :
Relying on DFU or Serial available thru Boot0 push button as described in STM docs.
When I first assembled the Frank’s STM32Stamp, I was using Serial with stm32loader.py, but it is less convenient.
So, that why I added it for those two boards STM32Stamp and Netduino.

Matrin,

OK. Adding serial is easy.

I’m not sure how you managed to upload via DFU, don’t you need a bootloader ??

I wasnt aware of a maple bootloader for F4. The F1 bootloader almost certainly won’t work on F4 as the setup and GPIO control etc are different.

But I’m sure it could be ported.

At the moment, the F4 code seems to have support for USB OTG, but I’m not entirely sure what it does. I tried to connect the OTG port to my PC but it doesnt enumerate, so I suspect is a USB host.

ummm.

Its starting to look more and more like I need to start the difficult process of merging the F4 and F1 codebase, but I suspect its days of work

Hi Roger,

For DFU, it is using the ROM bootloader which is provided by STM, it look to Serial port but also to USB, as long as the Boot0 is pushed while powering up. So, my sketch is loaded without any other bootloader for now.

And when I was mentioning a TCP bootloader, it doesn’t mean that all the code from your current bootloader is needed, maybe only few helpers, so don’t worry to much about that …

Martin,

OK about the built in DFU on the F4. On the F1 when boot0 is high on boot, it goes into serial bootloader mode, which is what I used to use all the time.

However now we have a generic bootloader that doesnt need any special external hardware on the F1 I tend to use that most of the time.

To do TCP uploads, I cant see how you can do that without either an external processor or a bootloader that communicates over TCP.
a TCP bootloader would be a lot different from the one on the F1, which is DFU

I’m not sure if there are any standards for TCP re-flashing, I guess so, as I think they were discussing it on the ESP8266 forum, but it could be a built in feature on the ESP8266 as its inherently a network device.

RogerClark wrote:<..>
To do TCP uploads, I cant see how you can do that without either an external processor or a bootloader that communicates over TCP.
a TCP bootloader would be a lot different from the one on the F1, which is DFU

I’m not sure if there are any standards for TCP re-flashing, I guess so, as I think they were discussing it on the ESP8266 forum, but it could be a built in feature on the ESP8266 as its inherently a network device.

@Ray, Indeed, it is interesting. I’ve tried it several years ago. But it serves completely different purposes : sharing USB devices across network.
@Roger, Effectively, there are not any standard. I’m following the ESP forums too, and recently, someone came up with RBoot, which I didn’t tried yet …

After the NSS vs CSN saga on SPI, I got the MicroSD working on my Netduino2Plus. I’ve used the SD lib, but I will try again Victor’s SdFat, it should work too since the problem was that famous NSS issue …