Netduino Plus 2 libmaple port

LeafLabs Garden » Support » Maple Hardware Support

Netduino Plus 2 libmaple port

(10 posts) (3 voices)

Started 2 years ago by slibert
Latest reply from mlundinse

slibert
Member

I'm starting work on a Netduino Plus 2 libmaple port.

My ultimate goal is to get Arduino-like code (esp. w/support for ENC28J60, SD card, XBEE and also to get the excellent I2C Device Library ported over and running on these targets:

- STM32F4DISCOVERY
- Netduino Plus 2

After poking around the forums and reviewing the different branches, I've decided to start w/the openstm32sw as a base.

Here's what I've encountered so far, if any of the experts have any insight on best practices, please let me know:

1) The USB OTG is not supported in the F2/F4 libmaple branches. I can see why, it's a pretty big change. I'd really like to get CDC working, but DFU would be nice too. I'm thinking of tackling this, but not until 2) is resolved. For what I can tell, ala42 has considered something like this but I haven't found anything concrete yet.

2) In general, the F405 (Netduino Plus 2) and F406 (STM32F4Discovery) have:

- More peripherals. Specifically, there's a USART6 that the Netduino Plus 2 really needs.
- More Interrupt Vectors. Includes USART6, ETH, More DMA 2 Channels, USB OTG and I2C3.

So here's the immediate question on 2). I'm starting to extend the existing STM32F4 (F2) code, changes appear reasonably minimal to get USART6 and the additional interrupt vectors added in. However, my current approach is to add some more kludgy #if defined (BOARD_netduinoplus2) statements while extending usart.h/.c, and nvic.h/.c. Seems like some sort of new symbol (like F405, or F4_DENSITY or something (?) more reasonable) should be used, otherwise we'll have BOARDxxx littered all over the place.

So my primary question here: does anyone have any recommendations for an approach to add USART6 and associated interrupts (and ultimately other details that are F405/F406 specific)?

I'd like to think I'd be following a standard and that would make it easier to potentially merge this into the main libmaple stream. I think the netduinoplus2 hardware support, and also the port of the i2cdevlib (www.i2cdevlib) would be helpful not only to me but others.

Thanks for any input you may have,

Cheers,

- scott

Posted 2 years ago #
gbulmer
Moderator

silbert - "I'm starting work on a Netduino Plus 2 libmaple port."
Kudos!

"I've decided to start w/the openstm32sw as a base."
I haven't got the link to hand, but you might want to track down ala42's code, which I believe has progressed further than the old github openstm32sw, unless that is the one you are using.

You say "2) In general, the ... and F406 (STM32F4Discovery) have"
Did you mean STM32F407?

"... Seems like some sort of new symbol (like F405, or F4_DENSITY or something (?) more reasonable) should be used ..."
Agreed. The extra peripherals and interrupts are dependant on the MCU no matter what board the chip is on. I'd define something like STM32F405, or STM32F407, and use #if defined with those.

Best of luck.

(Full disclosure: I am not a member of LeafLabs staff.)

Posted 2 years ago #
mlundinse
Member

There is quite some work done on perhipherials in the stm32f2 directories of the official branch, and their periherials are real close to stm32f4.

I am also looking into adapting USB to use OTG_FS. I have looked at the ST Driver and USB lib but, perhaps foolishly, this messy library makes me just tirerd to look at, so instead I am trying to get to grips with both the present USB code and the documentation of the OTG_FS hardware. ( so much for beeing tired and wasting time )

These driver libraries are overby their wish to wrap everthing up in some general function, which makes finding out to make even simples things almost as hard as reading their reference manuals. And in order to know whats happening you still must read the reference manuals.

There are some stm32f1 specific stuff in header files that are not stored in stmf32f1 folders. So making the old work nice with the new needs a careful touch.

Posted 2 years ago #
slibert
Member

gbulmer's tip (above) to look at ala42's STM32F4Discovery libmaple port was helpful - this port appears to have libmaple SerialUSB mapped onto the F4's OTG_FS. mlundinse, if you haven't already, you might want to take a look at this.

Source is in a zip file, at http://code.google.com/p/stm32f4discovery-libmaple/downloads/list.

Click on the libmaple.zip.

Like you, I find the process a bit daunting, but I think the goal of getting libmaple running on the more recent STM32 MCUs (which IMHO look to be some of the best out there in the MCU class) is worth it.

I'm new to the ARM, so learning curve will be steep - so if you have any tips or pointers, please let me know.

Posted 2 years ago #
mlundinse
Member

I have looked at ala42's stuff, and I find its great, but its not from me.
I want a nice clean usb implementation that can easily be mapped to the USB
protocol without a multilayer of spagetti fuction calls where configuration and dependencies are almost impossible to trace, but thats just me.

For other periperials I have libmaple gpio, uart, i2c and spi working on a DisvoveryF4 board by simply reusing the STMF2 stuff from the main repo.

Posted 2 years ago #
gbulmer
Moderator

slibert - If you haven't already done it, I'd recommend you investigate using the JTAG-SWD for hardware debugging.

The STM32F4Discovery has a JTAG-SWD (two-wire JTAG) hardware debugger built-in which can also be used on your Netduino Plus 2.
The JTAG-SWD debugger is a subset of the ST-LINK/V2 (quite low-cost, and supports both of ARM's Cortex-M JTAG interfaces)
http://www.st.com/web/catalog/tools/FM146/CL1984/SC720/SS1450/PF251168?s_searchtype=partnumber
It supports the usual debugging features, e.g. setting breakpoints, watching for a variables value to change, single stepping, etc.

There are a bunch of tools which can help you debug code, including gdb (in the toolchain). The ST-LINK/V2-based JTAG-SWD needs a gdb server, and one which folks use is at https://github.com/texane/stlink

Posted 2 years ago #
mlundinse
Member

open-ocd works quite well with stm32f4 and st-link/v2 these days also

Posted 2 years ago #
slibert
Member

Thanks for the guidance, gbulmer and mlundinse.

OTG_FS VCP is now up and running on discovery, so for me that's a great stride forward - thanks gbulmer. mlundinse, I see your point about code structure. At this stage in the game I'm likely to stick w/ala42's approach, waiting until I have a whole working development environment setup before embarking on that level of reorganization - but I'll keep it in mind.

Now that leds, buttons and usb serial are breathing on F4 discovery, getting it to work on the NP2 and source-level debugging are my next steps.

I've seen favorable comments about the black magic probe (has an embedded gdb server in it). Not sure if it's better to order/wait for that, or just dive into OpenOCD. If you have any insight into tradeoffs here, I'd be very grateful.

Thanks again for your support, hopefully I'll get to the point where I'm giving as much as I'm receiving. :)

Posted 2 years ago #
gbulmer
Moderator

slibert - LeafLabs have posted on a thread recommending the black magic probe. It directly understands the gdb remote debug protocol, so "it just works". They did use OpenOCD before that, and IIRC the post suggested that black magic probe is so much better that you wouldn't go back.

I, and a friend, have futzed around with configuring OpenOCD. I was not impressed.

My experience with https://github.com/texane/stlink is pretty good. (The only annoyance was the stlink makefile got a bit baroque for my taste in finding the USB library, but that is a matter of taste.).
Once compiled, run the stlink gdb server, start gdb (with the right connection syntax) and "it just works" (no configuration) with the STM32F4Discovery. Pull the two jumpers out, and wire the debugger on the STM32F4Discovery to the NP2, and that should work fine too.

Posted 2 years ago #
mlundinse
Member

@gbulmer You got a link to that thread on Black magic probe vs. openocd ? Or you tried it yourself ?

I cannot say that openocd is just easy out of the box, but part of the problem is badly written scripts and gdb trying to read in weird memory locations. I use openocd to connect diretly to STM32F4 Discovery borads using the onboard st-link and to a Netduino plus 2 using a separate J-link debug adapter with a 20 to 10 pin jtag adapter cable. The problem here was soldering the small 10pin male header to the netduino board (I am old with weak eyes)

Dont want to turn this thread into a openocd for/against argument but with a bit of setup its a useful tool.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.