Error flashing HY32 Board

After 2(!) months waiting for my HY 3.2" boards to arrive I finally get to try espruino \o/

Though on connecting it and flashing it I get an error! /o\

python stm32loader.py -p /dev/tty.usbserial -evw espruino_1v41_hystm32_32_vc.bin 

Reading data from espruino_1v41_hystm32_32_vc.bin
Bootloader version 0x22
Chip id 0x414, STM32F1, performance, high-density
Writing 208084 bytes to start address 0x8000000
Write 256 bytes at 0x8000000
Traceback (most recent call last):
  File "stm32loader.py", line 513, in 
    cmd.writeMemory(conf['address'], data)
  File "stm32loader.py", line 348, in writeMemory
    self.cmdWriteMemory(addr, data[offs:offs+256])
  File "stm32loader.py", line 211, in cmdWriteMemory
    self._wait_for_ack("0x31 address failed")
  File "stm32loader.py", line 87, in _wait_for_ack
    raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x31 address failed

I running this on a MacBook Pro (around early 2010 model) with mavericks.
Connecting it to the mac keyboard usb hub instead I got this error message:

python stm32loader.py -p /dev/tty.usbserial -evw espruino_1v41_hystm32_32_vc.bin 

Reading data from espruino_1v41_hystm32_32_vc.bin
Bootloader version 0x22
Chip id 0x414, STM32F1, performance, high-density
Traceback (most recent call last):
  File "stm32loader.py", line 508, in 
    cmd.cmdEraseMemory()
  File "stm32loader.py", line 228, in cmdEraseMemory
    if self.cmdGeneric(0x43):
  File "stm32loader.py", line 136, in cmdGeneric
    return self._wait_for_ack(hex(cmd))
  File "stm32loader.py", line 97, in _wait_for_ack
    raise CmdException("Chip replied with a NACK during %s" % info)
__main__.CmdException: Chip replied with a NACK during 0x43

I must be doing something wrong or have missed doing something. I've been following the guide at: http://www.espruino.com/Serial+Bootloader
On my board there's a button for boot0 and reset, when I press them the board shows a white screen and seems to be put in bootloader mode (as pressing the reset, resets the device and shows the demo program).

Hi Mudderman,

It looks like you're doing the right thing...

When the flasher says Chip replied with a NACK, have you tried just running the flasher again - without resetting the board? I've had that happen sometimes.

It's not a big deal if flashing fails and you need to do it again - the bootloader is built in to the chip, so you can never kill it.

Yep, first time running again:

Reading data from espruino_1v41_hystm32_32_vc.bin
Bootloader version 0x22
Traceback (most recent call last):
  File "stm32loader.py", line 493, in 
    chip_id = cmd.cmdGetID()
  File "stm32loader.py", line 163, in cmdGetID
    if self.cmdGeneric(0x02):
  File "stm32loader.py", line 136, in cmdGeneric
    return self._wait_for_ack(hex(cmd))
  File "stm32loader.py", line 97, in _wait_for_ack
    raise CmdException("Chip replied with a NACK during %s" % info)
__main__.CmdException: Chip replied with a NACK during 0x2

Running it again:

Reading data from espruino_1v41_hystm32_32_vc.bin
Bootloader version 0x22
Chip id 0x414, STM32F1, performance, high-density
Traceback (most recent call last):
  File "stm32loader.py", line 508, in 
    cmd.cmdEraseMemory()
  File "stm32loader.py", line 242, in cmdEraseMemory
    self._wait_for_ack("0x43 erasing failed")
  File "stm32loader.py", line 87, in _wait_for_ack
    raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x43 erasing failed

running it a third time puts it back to the first message Chip replied with a NACK during 0x43

I've also gotten:

Reading data from espruino_1v41_hystm32_32_vc.bin
Bootloader version 0x22
Chip id 0x414, STM32F1, performance, high-density
Writing 208084 bytes to start address 0x8000000
Write 256 bytes at 0x8000000
Traceback (most recent call last):
  File "stm32loader.py", line 513, in 
    cmd.writeMemory(conf['address'], data)
  File "stm32loader.py", line 348, in writeMemory
    self.cmdWriteMemory(addr, data[offs:offs+256])
  File "stm32loader.py", line 221, in cmdWriteMemory
    self._wait_for_ack("0x31 programming failed")
  File "stm32loader.py", line 87, in _wait_for_ack
    raise CmdException("No response to %s" % info)
__main__.CmdException: No response to 0x31 programming failed

:D

Can you try adding -b 9600 to the command-line? It'll force a much slower baud rate, which might help?

I can't say I've ever come across this problem before. Perhaps you could try another computer?

Managed to find my old linux computer and it worked like a charm! Thanks! I'm so looking forward to getting started using espruino now! Keep up the awesome work!

Great news! It's worrying that it doesn't work on your new Mac - I guess it could be a driver problem... I think some of the boards tend to use a cheap PL2303 USB-serial convertor that might be a knock-off of the 'real' Prolific one.

Well...would be so bold as to call my mac "new", but thanks ;)

I figured as much. When I first connected the card my MBP would even recognize the card as a usb device (in either of the mini-usb ports), googled it and found someone with similar problems which led me to the Prolific drivers and installed them. After that there was a /dev/tty.usbserial but only if I connected it to the mini-usb by the power led not the other one. But flashing failed and gave some random error messages as seen by my previous posts.

After flashing the card on my ubuntu machine (thank god I saved it in my closet) my MBP has no problem finding it and connecting to it on either mini-usb port.

Just wanted to add that you should check this out: http://forum.espruino.com/conversations/340/

The 3.2" board had an issue where there was at least 4x less memory than there should be

it seems to be a voltage problem, I just disconnect the LCD and fail much less (it is always buggy), but i took me 3 tryes to burn, instead of 200 and no success with the LCD connected.

I'm having the same problem here with the bootloader. I already tried other versions of bootloaders (stm32ld, stm32flash, stm32bootloader) and different drivers for the Prolific, it is always the same in my Mac with OSX 10.10. When I use the virtual machines in Linux or Windows it works. Do you continue with the same problem in your Mac? It must have to do with the driver, but I cant find one that works.