Porting to Nucleo-F413ZH

Posted on
of 2
/ 2
  • I'm going through the Espruino code I cloned from Github and was hoping it would be pretty simple to modify the pin assignments to get Espruino going on this dev board.

    I've changed as much as I know in a duplicated py file and modified the makefile to use it. I don't have a hold on the format of the pins CSV file and I'm not sure what the STLIB entry in the Makefile points to.

    I'm I missing anything else that might need to happen to get this running?


  • Hi,

    I think that's probably ok - the CSV files are just there to map peripherals to pins, but I'd have guessed that the 413 is very similar to the 411 - so you could probably just copy all the definitions from there?

    In fact you may find that you can run the Nucleo 411 image directly?

    One annoyance is that ST drastically changed their peripheral library a year or so back and stopped supporting the old one (which Espruino uses) - so it's more difficult to get newer chips running with it :( But you may have some luck by just copying ST's STM32F413xx.h file over

  • Hey Gordon!

    I worked on this over the weekend and found out exactly what you're talking about. I was trying to get the new (1.8.0) peripheral library to work in the existing Espruino codebase and it was a disaster. Seems it has changed a lot. 1.8.0 directly supports the F413.

    I think I did try the F411 image but the board was unresponsive over serial through the onboard ST-Link setup. I was thinking maybe it was just the USART setup, I'll have to continue matching up all the pinouts.

    I really hope to get this working so I can add a CAN Bus plugin to Espruino. The idea is to create a board with three CAN channels and this new chip is the only F4 with three CAN controllers. It looks like it just came out about a month ago so resources are pretty sparse at the moment.

  • Yes, it's been a constant pain for me. The 'new & improved' library is (or was when I tried) hugely bloated and not set up for interpreted languages at all.

    As a result I'd have had to have dropped support for any 128kB device and anything with less than 20kB RAM, so I just kept using the old libs instead. I spent at least a week doing porting before I realised it wasn't going to work.

    the board was unresponsive over serial through the onboard ST-Link setup.

    It could just be to do with the clock on it - it you put a scope on the UART pin you might find it transmits something, but at the wrong speed. If you poke around in the targetlibs/stm32f4/lib/system_stm32f4xx.­c you might be able to fiddle with the clock divisors.

  • I set the clock to what should be 100mhz i believe. And I added the pin number from the datasheet to the stm32f401.csv file. No love.

    The TX from the MCU seems to be sitting around +/-1vdc so I'm thinking it's not properly configured. Looking at the nucleo 144 board schematics RX/TX to the STLink are indeed the same PA2 and PA3.

    This is my first real dive into the world of stm32. While I've used pic and atmegas this stuff is new to me. Any other thoughts on stuff I could look into?

    Check out the image from my logic analyzer attached.

    1 Attachment

    • Screen Shot 2017-01-30 at 10.01.30 PM.png
  • What's channel 1? That looks a lot like a serial transmission

  • Yep, indeed it is. Channel 1 is the TX from the ST-Link to the F413 which is working as expected. But Channel 0 is the TX from the F413 and it is oddly moving with the other line.

    I thought it was a bad ground but i checked the ground to the logic analizer was good so my only other thought is the pin is maybe not configured so it's floating.

  • Hmm - yes, looks like it's not configured then. I'm afraid I'm not sure what to suggest - it'll be a matter of diving into the ST peripheral libraries, but I just don't have time to help with that.

    Recently ST have been porting Espruino to their new 'Low Level' libs - targets/stm32_ll - and you might find that you can get a compile working with that?

  • Ok, I'll keep at it. Thanks for the help!

  • Just heard back from ST - at the moment it seems there is no version of the 'Low Level' libs for the F4 (it's just the L4) - but this should come in the next 6 months:


  • Well it's neat that they are undertaking that!

    So I have some good news. Sometimes it's the simple answer... I've got it running with the regular f411re bin.

    Looking at the schematics of the Nucleo 144 board it shows the serial RX/TX connected to PA2/3 (USART2) and the two pin header on the ST-Link (CN5). But they are actually connected to USART3! Great! So simply jumping the PBA2/3 to the RX/TX on the ST-Link is working and I can get a serial terminal.

    I'm trying to switch to USART3 in the Board file but looks like USART3 is not defined in the libs. No worries for what I'm trying to design, but it would be nice to setup a proper board file for this new Nucleo so I can submit a PR to your Espruino repo.

  • Great, thanks! You might well find that pulling the stm32f413xx.h (or whatever it's called) from ST's new libs and integrating it with what's there might work to add UART3 - I think that's what I did for the STM32F411.

  • That was my thought as well. For now I tried to just copy the USART3 definitions i need to test and i'll go back and clean it up once it works.

    I still dont have a grasp on how the CSV file defines the pins. Can I find any docs on that?

    I'm changing the variables in the BOARD.py file like so:

     'default_console' : "EV_SERIAL3",
     'default_console_tx' : "D8",
     'default_console_rx' : "D9",

    But once I do that the python scripts don't properly generate the platform_config.h and a make gives me this:

    Cleaning targets
    Generating platform configs
    Generating pin info
    make: *** [/Users/dkuschel/Desktop/Espruino/gen/pl­atform_config.h] Error 1

    Any thoughts on what I'm doing wrong?

    After working on this a little more I got the new stm32f413xx.h in the code base and building correctly. I made a new CSV file from the datasheets for the 144 pinout.

    Now if I keep A2 and A3 physically jumped to D8 and D9 with an airwire I can get a terminal through the ST Link and I can toggle D8 and D9 manually with set() and reset() so that tells me the pin configuration is correct. Of course this interrupts the terminal from functioning. But if I set the default_console to EV_SERIAL3 as outlined above I can't get a terminal going.

  • This will probably help? https://github.com/espruino/Espruino/blo­b/master/README_BuildProcess.md

    I guess it's possible that some of the serial stuff in jshardware.c just isn't defined for USART3? Not sure. What I'd suggest is to use A2/A3 then see if you can use Serial3.setup and Serial3.write/.on('data',...) from JS to try and get USART3 working - it might give you some human-readable errors that would help :)

  • Looks like the the MCU is crashing when I write to Serial3 or when it receives any data. I can call Serial3.setup fine. Being new to STM32 I'm not sure where to start looking. Maybe st-util and gdb but I'm pretty green with gdb.

    This board has a micro USB connector, maybe I'll switch gears and see if I can get anything going on that for the time being.

  • USB can be even more tricky I'm afraid - but it's worth a go :)

    Not sure where to suggest really - just look in jshardware.c (and I think there's one to handle interrupts as well?) and see if UART3 is defined and used in all the places that USART1 and 2 are...

  • Hi Gordon
    I do appreciate an advise on porting Espruino to NUCLEO-L432KC dev board, or is any of the current images will work with it?

  • There's a port to the L476 available here: http://www.espruino.com/binaries/travis/­master/

    But that's unlikely to work. It might be possible to modify, but that port was done by the guys at ST themselves, so I couldn't be much help - except to say that the code you'd be dealing with is in the stm32_ll directories: https://github.com/espruino/Espruino/tre­e/master/targets/stm32_ll

  • Thanks

  • I managed to get it going! Another stm32 newbie mistake, but it's been fun learning. Also, the build system is pretty impressive. Good work @Gordon!

    I had to simply add a word entry for USART3 interrupt to the startup_stm32f401xx.s file the build was using. It was probably simply crashing when calling the interrupt. When trying to bring in the whole newer startup_stm32f413xx.c from the newer lib I have a problem linking. I'm going to continue cleaning things up and trying to make a proper startup for this board so I can do a PR.

    Going to try to see what I can get going on the USB side of things as this board has a built in micro USB connector.

    Could I increase the amount of jsvars in the board.py file? This chip has 320k of ram, quite a bit more than the f401.

    Thanks for all of your guidance @Gordon! I look forward to contributing back to the repo.

  • Great! If you can add USART3 to that startup file in a way that won't cause problems for other boards it'd be great to get it in there :)

    Yes, you should be able to increase the number of vars. Just make sure that the RAM is in one contiguous block - I know on some F4s it wasn't - so if you wanted to increase vars a lot in that case you'd have to mess with the linker to maybe put the variables in the second block of RAM.

  • I'm just making new files for the F413 so everything should be separated out.

    I'm not sure why I get build errors when I change the 'chip' in the board.py file.

    But I did just get USB working on the board by disabling vbus_sense_enable in usbd_conf.c

  • Did you ever get a chance to do this? I'm interested in playing about with some F412/413 chips and it'd be nice not to have to redo your work.

  • I did indeed. I've been traveling and just returned home. Let me clean up the code and I'll do a PR asap!

  • Thanks!

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Porting to Nucleo-F413ZH

Posted by Avatar for user63214 @user63214