installing espruino on stm32F100 based diy project

Hi, I am trying to install Espruino on stm32f100 chip and use it in my DIY nixie clock project. I found that STM32VLDISCOVERY board is based on the exact same chip. I used it's firmware and flashed it on my chip using JTAG programmer (made from a raspberry pi + openOCD). The programmer says that the firmware is flashed successfully, but when I connect to the chip's uart with minicom -o -b 9600 -D /dev/ttyAMA0 i get nothing. There is no Espruino console.

Here is how my wiring looks like:

Here is what I had tried:
1) Checked my wiring (I tried it in multiple ways. I also tried to connect to my MacBook using USB-TTL dongle, I can see the dongle from Espruino ide, but it cannot connect to the chip)
2) I followed this forum post
3) I made a custom build based on STM32VLDISCOVERY and changed the package to LQFP48 to match my chip

I also found some weird behavior.
In boards/STM32VLDISCOVERY.py in devices section, there are JTAG pins defined

'JTAG' : {
        'pin_MS' : 'A13',
        'pin_CK' : 'A14',
        'pin_DI' : 'A15'
}

But after flashing the programmer can't connect to the chip again without "connect under reset" procedure, which means that this pins have been overwritten.

Any clues will be appreciated

Is there a spare pin there that you could set up as LED1 in the board python file?

When starting Espruino should flash LED1 once during the init process. Usually Espruino disables JTAG/SWD on those pins so they're available for other stuff (https://github.com/espruino/Espruino/blob/master/targets/stm32/jshardware.c#L1228) so the fact that is happening is actually good news - it's running at least some code.

What could be happening is that the oscillator is set up wrong and the CPU is actually running at the wrong frequency. Do you have an oscilloscope or something you can put on the TX pin? Espruino should transmit some text at boot and by looking at it you could see if the bit rate is actually 9600 or if it's something else.

Just to add, I tried out the VLDiscovery build just now and while it works on the board, it was impossible to do much - it crashed almost immediately because I believe there wasn't much RAM left for stack.

I've just tweaked the variable count - from 500 down to 400, and it works much more reliably (although I don't think that was actually your problem).

Thanks for a quick response and your awesome project, @Gordon.

I set the LED1 to A13. My devices block looks like this

devices = {
  'OSC' : { 'pin_1' :  'D0',
            'pin_2' : 'D1' },
  'LED1' : { 'pin' : 'A13' },
};

Indeed, the LED makes one really short flash when the board is powered on. Looks like Espruino is there, but minicom connection to UART is still silent. As far as I know, if the bit rate is mismatched you should get at least some weird ASCII symbols instead of data. But I get nothing. I reduced the number of variables to 400 just to be sure. Also, I added this two lines

 'default_console_tx' : "A9",
 'default_console_rx' : "A10",

Not sure if they really change something for the build. I copied them from the original Espruino board config.

400 variables are still more than enough for me. I need to blink some LEDs and control some transistors. By the way, can my chip store some code at all? I really like the idea of programming a chip with js, I can't wait to make it work)

Have you got tx and rx the wrong way around?

If you don't have a scope, maybe you could stick a LED between A9 and 3.3v and see it it at least flashes on boot? Espruino should transmit its logo at startup so you should see it flashing if that's the case.

If that works then you can narrow it down to something with the USB TTL dongle... You have connected GND as well as RX and TX?

I did what you said. The LED connected between A9 and 3.3V is not flashing. I made a second board from fresh components just in case I broke something but had the same effect. Looks like the chip is not sending anything to this UART. Maybe there is a pin configuration issue? Maybe because the default package for STM32VLDISCOVERY is LQFP64 and mine is LQFP48 (i changed it in board's config file) there is some pin mismatch? Or some connections on my board make the chip think that it is connected via USB, so it sends nothing to A9, A10 pins?

You could try adding DEFINES+=-DPIN_NAMES_DIRECT=1 to the python file (check out PICO_R1_3.py for an example).

If the package is such that not all pins on a port are brought out it can break the pin naming, so that could be an issue. You could also try explicitly setting the default_console device to Serial1 and see if that helps?

I added this to the info block

 'default_console' : "EV_SERIAL1",
 'default_console_tx' : "A9",
 'default_console_rx' : "A10",

And this to the Makefile list

'DEFINES+=-DPIN_NAMES_DIRECT=1',

With no effect, unfortunately.

By the way, I checked the CSV table stm32f103xb.csv from which it scans the pins from

And they look correct.

I found something interesting. This 6, 10, 11 offset numbers in get__pins function. I never changed them, I just copied them from VLDISCOVERY file. Maybe they need to be changed as well because my chip package is different? But i cant figure out how they work

def get_pins():
      pins = pinutils.scan_pin_file([], 'stm32f103xb.csv', 6, 10, 11)
      return pinutils.only_from_package(pinutils.fill_gaps_in_pin_list(pins), chip["package"])

No, that should all be fine. You can check in gen/jspininfo.c (I think?) to see that it's got all the data correctly.

Actually I just had a thought - are you sure it's the same chip? Your circuit diagram says STM32F100C8T6B which only has 64kB flash. That wouldn't be enough for Espruino - the VL board has 128kB which is the absolute minimum

Unfortunately, I made the diagram and printed the PCB before I heard about your project. I replaced that chip with STM32F100CBT68 with 128kb of flash. This is the biggest chip in the LQFP48 package and I can't go bigger. But 128 should be enough. By the way, is it possible to store some code on 128kb chip?

Here is my gen/jspininfo.c file https://gist.github.com/Fxlr8/33115ccc6c6ba4e48aceec74713bebcc

is this correct if hardware pin numbers are 30 and 31?

Upd: I think this information from jspininfo.h is essential for the answer (i removed define at the beginning of every line because it messed up with the markdown)

JSH_PIN_COUNT 37

JSH_PORTA_COUNT 16
JSH_PORTB_COUNT 16
JSH_PORTC_COUNT 16
JSH_PORTD_COUNT 2
JSH_PORTE_COUNT 0
JSH_PORTF_COUNT 0
JSH_PORTG_COUNT 0
JSH_PORTH_COUNT 0
JSH_PORTI_COUNT 0
JSH_PORTV_COUNT 0
JSH_PORTA_OFFSET 0
JSH_PORTB_OFFSET 16
JSH_PORTC_OFFSET 32
JSH_PORTD_OFFSET 35
JSH_PORTE_OFFSET -1
JSH_PORTF_OFFSET -1
JSH_PORTG_OFFSET -1
JSH_PORTH_OFFSET -1
JSH_PORTI_OFFSET -1
JSH_PORTV_OFFSET -1

JSH_PININFO_FUNCTIONS 3

is it possible to store some code on 128kb chip?

Yes, absolutely. There's not much space available, but it's enough - besides, there's not too much RAM either :)

I think you'll need the PIN_NAMES_DIRECT command - because it looks like Port C probably only has 3 pins in it, despite JSH_PORTC_COUNT being 16? I'd only know if you posted the whole .c file to be sure though.

Either way that should affect the UART, since it's on port A which is earlier in the pin array.

Honestly I'm not too sure what to suggest at this point - maybe check gen/platform_config.h and make sure everything looks ok - but if it does then really you need to look at a debugger. You could start adding jshPinSetValue(LED1_PININDEX,1); type commands in the code to try and get an idea of whether it's actually running or not I guess.

Hi, Gordon. I updated my previous answer with a link to a full .c file.

I tried adding PIN_NAMES_DIRECT to my config like this

   'makefile' : [
     'DEFINES+=-DPIN_NAMES_DIRECT=1',
     'STLIB=STM32F401xE',
     'SAVE_ON_FLASH=1',
     'STLIB=STM32F10X_MD_VL',
     'PRECOMPILED_OBJS+=$(ROOT)/targetlibs/stm32f1/lib/startup_stm32f10x_md_vl.o'
   ]

but it didn't change anything in jspininfo.h, jspininfo.c, platform_config.h after the build. What does this command even affect?

Here is my gen/platform_config.h file just for sure.

PIN_NAMES_DIRECT doesn't affect those files, but it affects how a pin name such as C13 turns into an index in the jspininfo.c array. It may not fix this but it'll fix other stuff when you get it all working

I searched the repo with "LQFP48" to find similar boards and some clues. I found that Olmexino and Maple mini are the only boards with this package and they both have a special get_pins function. Maybe this solves my problem?

def get_pins():
  pins = pinutils.scan_pin_file([], 'stm32f103xb.csv', 6, 10, 11)
  # Olimexino/Maple pins have stupid names
  pinmapping = {
    'D0' :'PA3',
    'D1' :'PA2',
    'D2' :'PA0',
    'D3' :'PA1',
    'D4' :'PB5',
    'D5' :'PB6',
    'D6' :'PA8',
    'D7' :'PA9',
    'D8' :'PA10',
    'D9' :'PB7',
    'D10':'PA4',
    'D11':'PA7',
    'D12':'PA6',
    'D13':'PA5',
    'D14':'PB8',
    'D15':'PC0', # shared with A0-A15
    'D16':'PC1',
    'D17':'PC2',
    'D18':'PC3',
    'D19':'PC4',
    'D20':'PC5',
    'D21':'PC13',
    'D22':'PC14',
    'D23':'PC15',
    'D24':'PB9',
    'D25':'PD2',
    'D26':'PC10',
    'D27':'PB0',
    'D28':'PB1',
    'D29':'PB10',
    'D30':'PB11',
    'D31':'PB12',
    'D32':'PB13',
    'D33':'PB14',
    'D34':'PB15',
    'D35':'PC6',
    'D36':'PC7',
    'D37':'PC8',
    'D38':'PC9', # for button
    'D39':'PC12', # for USB disc
    'D40':'PA11', # for USB dm
    'D41':'PA12', # for USB dp
  };
  newpins = []
  for newname in pinmapping:
#    print newname
    pin = pinutils.findpin(pins, pinmapping[newname], True)
    pin["name"] = "P"+newname
    pin["sortingname"] = newname[0] + newname[1:].rjust(2,'0')
    newpins.append(pin)
  # Because 'pinmapping' is NOT stored in order!!!
  newpins = sorted(newpins, key=lambda pin: pin["sortingname"])
#  print(json.dumps(newpins, sort_keys=True, indent=2))
  return newpins

I pasted it to get__pins function in my file, but now I get this error on build. How can i get more info on what happened?

Generating platform configs
Generating pin info
make: *** [gen/platform_config.h] Error 1

That's not the issue - that function is when pin names don't match that actual chip.

Your files look ok, so honestly I'd start trying to turn pins on and off to see what is going on.

Are you sure you installed the right compiler, using the provision script?

Where should I put the jshPinSetValue(LED1_PININDEX,1); line to make it compiled into the firmware?

maybe try some different places, but as a start:

• Stick one at the beginning of jshIdle (https://github.com/espruino/Espruino/blob/master/targets/stm32/jshardware.c#L1349) and another at the end that sets to 0.
  
• Try one around jshDoSysTick (https://github.com/espruino/Espruino/blob/master/targets/stm32/jshardware.c#L745) - ideally on a different pin but if not take turns.
  
  

Ideally they should both end up getting called and flashing the LED.

You could also try this at the end of jsiSoftInit (https://github.com/espruino/Espruino/blob/master/src/jsinteractive.c#L438)

jsvUnLock(jspEvaluate("setInterval('LED.toggle()',500)", true));

In fact maybe just try doing that last one on its own - if the LED flashes then Espruino is working, it's just the serial that's not set up right.

Finally! It works! I just tried to build it with docker (i had to tinker a docker file a little bit) and it worked. I think the problem was with my build environment. Thank you for help. I can make a pull request with configs for vanilla STM32F100 LQFP48 package if you wish. Now I am going to become your patreon supporter.

That's great - thanks!

I'm afraid I wouldn't take any new BOARD.py files at the moment - there are 50+ at the moment and it's making my life a nightmare to change/maintain anything :)

However, what changes did you have to make to Docker, and how did you get it working? Ideally I'd be able to make it so it 'just worked'.

I created a pull request with my dockerfile here https://github.com/espruino/Espruino/pull/1543

Thanks!