Problems Getting FiPy and Expansion 3.1 working

[cgarai]

I am trying to get started with my first pycom project. I have a FiPy with an expansion board 3.1.

1. I can't get into the DFU mode to do an update in Zadig. Or perhaps I should say that Zadig takes longer to recognize the board than the board stays in DFU mode. Like the link below, I can see it come up in DFU mode in Device Manager and then switch to COM.

Re: Expansion board 3.1 firmware zadig HELP

I can get the USB Serial CDC driver updated in normal mode. When I try to use pymakr in Atom it tries to connect to the comm port COM5, but the python command line doesn't come up. I do see Connected with a green checkmark. At that point if I try to More/Get Wifi SSID or More/Get firmware version nothing happens. More/Help works, and the >>> python cursor appears but doesn't respond to input.
I'm running 1.16.1 and 1.20.1.r1 firmware. I don't know which is which though. PycomUpdateFirmware says 1.16.1 when it starts, but then says it's uploading 1.20.1.r1 for the fipy.

Any hints on how to get this running? I have sent a picture of the QR code on the board to pycom support. I could not get my QR readers to decode it.

What is the difference between DFU and normal mode?
Thanks,
Chris

[robert-hh]

@cgarai 1.16.1 is the version of the updater app, 1.20.1r1 the version of the FiPy firmware. This new pybytes version does not match the documentation any more, in that is does not create the AP by default, and it cannot be interrupted with Ctrl-C. And it start the pybytes background task by default, which is not helpfule in case of a fresh start. At least, it should respond to a serial terminal. In order to exclude pymakr issues, you could try a simple serial terminal app like Putty.

[crumble]

There is a second microcontroler on the expanion board, called PIC. The DFU mode is needed to update the firmware of the PIC. There was no update for this one for a long time. So you don't need DFU mode.

The Zadig driver is not good anyway. At best you use a linux system when you need to update the PIC.

[cgarai]

@robert-hh Should I roll it back to an earlier version?

[robert-hh]

@cgarai When using the pycom updater, you can choose between the pybytes and the legacy version. It cannot hurt a lot to try the legacy version.
Edit: If the problem is the Expansion board being stuck in update mode for itself, then you cannot change the FiPy firmware anyhow. But it should not be necessary to update the expansion board.

[cgarai]

I'm trying to connect with PuTTY via USB. Device Manager shows Expansion3 as COM5. I set up PuTTy as Serial, 115200 baud, 8bits, 1 stop, no parity, no flow control. These match the settings in Device Manager Expansion3 Port Settings.
Clicking Open I just get a terminal window with an unresponsive green cursor.

No AP is visible on WiFi

I would really like to use pymakr in Atom. But that is still not working also

[robert-hh]

@cgarai The Putty setting are fine. As long as it does not respond with Putty, it will not with PyMakr. Even the new Pybytes firmware should have a REPL prompt at USB. Are all Jumpers in place on the expansion board?

[cgarai]

@robert-hh I removed the RTS and CTS jumpers. I read somewhere that they are used by fipi

I just installed 1.18.3 and it is now working! pymakr in atom appears to work and the AP is now visible.
Thanks!

[robert-hh]

@cgarai So it is again a Pybytes fail. If you want to use 1.20.1r1, @andreas keeps a web page with 1.20.1r1 firmware images w/o pybytes.
https://packages.hiveeyes.org/hiveeyes/foss/pycom
Edit: Given the trouble people have with the pybytes build, pycom should provide recent releases w/o pybytes.

[andreas]

@robert-hh said in Problems Getting FiPy and Expansion 3.1 working:

@andreas keeps a web page with 1.20.1r1 firmware images w/o pybytes.

We are even doing builds with Pybytes these days, see https://packages.hiveeyes.org/hiveeyes/foss/pycom/pybytes/.

@robert-hh said in Problems Getting FiPy and Expansion 3.1 working:

This new pybytes version does not match the documentation any more, in that is does not create the AP by default, and it cannot be interrupted with Ctrl-C.

They should run more stable by mitigating different issues and CTRL-C should also work again.