bitbang adaptor on cross-compiled mips32 build

[andy-preston]

I've got a problem around line 1198 of adapter-bitbang.c
I'm cross-compiling for OpenWRT 18.06.1 on mips32.

When I run a terminal emulator at 115200 baud and send the "?" command to the bitbang adaptor (an ATMEGA 328p on a serial/USB adaptor) I get back the expected "ascii ICSP v1E" string.

But when adapter-bitbang.c does the same thing, I get back a single character "a".

Can anyone give me a tip that might help me?

I was tempted to try a different baud rate but, currently if I try to use "-b 5" (I have to try this again because, looking at source comments, this should be "-b5") then pic32prog segfaults.

I have build pic32prog using OpenWRT's installed libhidapi-libusb rather than the submodule contained in pic32prog's git tree. (#59) but I don't think this effects the bitbang adaptor.

My next step is to try an ordinary Arduino Nano instead of my custom adaptor both an ordinary X86 Linux and my mips32 OpenWRT system, and see what results I get there. And use the "-D" option.

But if anyone who's more familiar with this code has any ideas, I'd be glad to hear them.

[robert-rozee]

hmmm,
i may be one of the guilty parties!

firstly, the -b switch MUST occur AFTER the -d switch to specify the comm port. if it appears BEFORE the -d switch you will get a segmentation fault. this is a known problem, but i've never figured out an elegant solution to solve it. the solution therefore: -d then -b.

secondly, the -b switch has TWO special functions within bitbang.c as follows:

1. upload firmware (embedded within pic32prog) to an attached arduino nano:
   -b1 upload firmware to the arduino nano at 9600 baud,
   -b2 upload firmware to the arduino nano at 19200,
   -b3 upload firmware to the arduino nano at 57600,
   -b4 upload firmware to the arduino nano at 115200
   the normal bootloader speed for an arduino nano is 57600 (hence the -b3), but there is no guarantee that someone out there hasn't produced a bootloader with something different and burnt it to a nano.

once you have the firmware uploaded into your nano, you do not need to use the -b [1..4] switch again.

2. erase an otherwise unresponsive PIC32. very occasionally you can get a PIC32 into a state whereby it will NOT respond to an ID request. this results in the normal erase procedure used by pic32prog not working. the following switches are a workaround for this:
   -b8 'blind' erase a PIC32 MX
   -b9 'blind' erase a PIC32 MZ
   note that the -b8 and -b9 switches ONLY work for bitbang adapters.

someone really should place the above points into the pic32prog readme file! as well as a link to the .pdf schematic contained in the bitbang directory.

since you are seeing the "ascii ICSP v1E" string, i assume you have succesfully used pic32prog to upload the firmware into your arduino nano? can you please confirm this? note that just compiling the .ino file in the bitbang directory and uploading it to the arduino nano using the arduino IDE is not a good idea, as one of the libraries in the IDE needs to be patched first (instructions at the top of the .ino file).

jumping forward a little, the problem with only seeing a single character "a" returned is most likely due to an issue in 'serial.c', which was written by serge. but we'll get onto this once we are sure that your nano has the correct firmware uploaded to it.

cheers,
robert rozee :-)