Espruino JavaScript
Porting to Nucleo-F413ZH #6761
Replies: 1 comment
-
|
Posted at 2017-01-30 by @gfwilliams 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 Posted at 2017-01-30 by user63214 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. Posted at 2017-01-30 by @gfwilliams 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.
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 Posted at 2017-01-31 by user63214 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. Attachments: Posted at 2017-01-31 by @gfwilliams What's channel 1? That looks a lot like a serial transmission Posted at 2017-01-31 by user63214 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. Posted at 2017-02-01 by @gfwilliams 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 - Posted at 2017-02-02 by user63214 Ok, I'll keep at it. Thanks for the help! Posted at 2017-02-02 by @gfwilliams 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: Posted at 2017-02-03 by user63214 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. Posted at 2017-02-03 by @gfwilliams Great, thanks! You might well find that pulling the Posted at 2017-02-04 by user63214 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: But once I do that the python scripts don't properly generate the platform_config.h and a make gives me this: Any thoughts on what I'm doing wrong? Edit: 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. Posted at 2017-02-06 by @gfwilliams This will probably help? https://github.com/espruino/Espruino/blob/master/README_BuildProcess.md I guess it's possible that some of the serial stuff in Posted at 2017-02-12 by user63214 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. Posted at 2017-02-13 by @gfwilliams USB can be even more tricky I'm afraid - but it's worth a go :) Not sure where to suggest really - just look in Posted at 2017-02-13 by user73705 Hi Gordon Posted at 2017-02-13 by @gfwilliams 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/tree/master/targets/stm32_ll Posted at 2017-02-13 by user73705 Thanks Posted at 2017-02-16 by user63214 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 @gfwilliams! 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 @gfwilliams! I look forward to contributing back to the repo. Posted at 2017-02-20 by @gfwilliams 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. Posted at 2017-02-21 by user63214 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 Posted at 2017-03-01 by @gfwilliams 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. Posted at 2017-03-03 by user63214 I did indeed. I've been traveling and just returned home. Let me clean up the code and I'll do a PR asap! Posted at 2017-03-03 by @gfwilliams Thanks! Posted at 2017-03-08 by user63214 Doing a PR now Posted at 2017-03-08 by @gfwilliams Got it - thanks! Looks good. I'm just in the process of changing the build process, but I'll merge it in after that's done Posted at 2017-03-10 by user63214 I'm going to work on a CAN plugin next. I'll submit it back to the repo if you're interested. Thanks for all your help getting this going on the new Nucleo. I look forward to contributing more to the project! Posted at 2017-03-10 by @gfwilliams Thanks, that's be great! I'd be really interested to see how you get on with it. Can you try and make it something in Posted at 2017-03-15 by user63214 Definitely! That's what I was planning on. The info on plugins on the espruino site was super helpful. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2017-01-28 by user63214
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?
Thanks!
Beta Was this translation helpful? Give feedback.
All reactions