Command line flag order matters

[vidavidorra]

Originates from #15. When programming using the command line (on Windows 10, yet to be tested on OSX) the order of the flags matters for the program's behaviour.

The following example is not programming the device but is just resetting it. So only the --mclr option seems to do something.

BullyCPP-0.8.1-win32.exe --no-gui --device COM4 --baud 115200 --mclr file.hex

The next example is doing what is expected, programming the device with file test.hex.

BullyCPP-0.8.1-win32.exe --baud 115200 --no-gui --device COM4 --mclr test.hex

So the order

--no-gui --device --baud --mclr <hex file>

is not working and the order

--baud --no-gui --device --mclr <hex file>

is working. As mentioned earlier this behaviour is only seen on Windows. I will do some tests this weekend to see if this is also the case on OSX.

[thirtythreeforty]

This is really weird. I found and fixed (396795f6b43c16b2fe0bca133740a1b56f8e5c25) an issue that prevented errors from getting reported on the command line; I'll upload a packaged Windows build for you to retry with soon. However, the order of the command line arguments should make absolutely no difference, unless there is a Qt bug in the argument parser. (I hope I don't have to eat those words, heh...)

Question for you: Does v0.8.1 give any output at all with the bad ordering of flags? Don't forget to launch it from MPLAB so the output is captured.

[vidavidorra]

Ok, I ran the two command line options orders that I showed in the first post. First the one with the --no-gui option first and than the one with the --baud option first. (See results below.) For testing I actually wrapped the output of BullyCPP to a text file. And yes, v0.8.1 does give output with the 'bad' flag ordering. So the order actually does seem to make a difference...

--no-gui first

Executed command

C:\Program Files (x86)\BullyCPP>BullyCPP-0.8.1-win32.exe --no-gui --device COM4 --baud 115200 --mclr file.hex >> C:\Users\jdebruijn\Documents\no-gui_first.log

Result _(in file no-guifirst.log)

Initializing... OK
Reading firmware version...
Firmware version: 3.0, config bits programming disabled.
Firmware v3.0 or later detected.
No pages below location 0xc00 will be written.
Reading hex file...

--baud first

Executed command

C:\Program Files (x86)\BullyCPP>BullyCPP-0.8.1-win32.exe --baud 115200 --no-gui --device COM4 --mclr test.hex >> C:\Users\jdebruijn\Documents\baud_first.log

Result _(in file baudfirst.log)

Initializing... OK
Reading firmware version...
Firmware version: 3.0, config bits programming disabled.
Firmware v3.0 or later detected.
No pages below location 0xc00 will be written.
Reading hex file...
Hex file read successfully.
Programming device...
Mem Address: 0xc00
Mem Address: 0x1000
Mem Address: 0x1400
Mem Address: 0x1800
Mem Address: 0x1c00
Mem Address: 0x2000
Mem Address: 0x2400
Mem Address: 0x2800
Mem Address: 0x2c00
Mem Address: 0x3000
Mem Address: 0x3400
Mem Address: 0x3800
Mem Address: 0x3c00
Mem Address: 0x4000
Mem Address: 0x4400
Mem Address: 0x4800
Mem Address: 0x4c00
Mem Address: 0x5000
Mem Address: 0x5400
Skipping memory row a800 on config bit page

Verifying...
Mem Address: 0xc00
Mem Address: 0x1000
Mem Address: 0x1400
Mem Address: 0x1800
Mem Address: 0x1c00
Mem Address: 0x2000
Mem Address: 0x2400
Mem Address: 0x2800
Mem Address: 0x2c00
Mem Address: 0x3000
Mem Address: 0x3400
Mem Address: 0x3800
Mem Address: 0x3c00
Mem Address: 0x4000
Mem Address: 0x4400
Mem Address: 0x4800
Mem Address: 0x4c00
Mem Address: 0x5000
Mem Address: 0x5400
Skipping memory row a800 on config bit page
Done!

[thirtythreeforty]

(I edited a couple typos in your post...)

That is very weird, although there is obviously a problem! It seems like it's throwing an error somewhere in the hex file parser (which is caught silently instead of being displayed, which is what I just fixed above). I've zipped up a build with the fix (edit, use link below) that should at least say what the error is. Could you retry the bad command with it? Be sure you unzip everything, because it won't run without all the DLLs like my usual releases.

[vidavidorra]

I have tried to run the build you uploaded, but it gives me the warning

This application fialed to start because it could not find or load the Qt platform plugin "windows".  
Reinstalling the application may fix this problem.

Googled the error and found this post. Seems some dll files are missing?

I've extracted the complete folder as you said.
Also tried copying the libEGLd.dll and libEGL.dll from my Qt 5.5.1 directory to the BullyCPP.exe dir, but no improvement.

(Edit:) I've tried both launching the BullyCPP gui and running it from the command line, both gave me the same warning.

[thirtythreeforty]

Blegh, sorry for the trouble. I hate DLLs. Now that I have access to my big computer again, here's a static version that should just work.

[vidavidorra]

Thanks for the static version. As a test I was running the command that should work (with the --baud option first), but even that gives me a error now. It seems to be failing to open the serial port, even though I'm sure the port is correct. Running the command without the no gui option shows the gui with the options filled in, and when I click program it programs the MCU just fine.
I even tried running it with admin rights and that didn't help..

C:\Windows\system32>C:\Users\jdebruijn\Desktop\test\BullyCPP.exe --baud 115200 --no-gui --device COM5 --mclr C:\Users\jdebruijn\Desktop\test\test.hex
Initializing... C:\Users\jdebruijn\Desktop\test\BullyCPPw: Failed to open serial port: The system cannot find the path specified.

[vidavidorra]

@thirtythreeforty I've tried again using the static version that you posted above, but am still running at the

Initializing... C:\Users\jdebruijn\Downloads\t\BullyCPPw: Failed to open serial port: The system cannot find the path specified.

error. I've tried putting the --device COM4 command in every possible place in the arguments, but that doesn't change a thing.
Also the bad command (with 'bad' argument order) gives me exactly the same error. Is it possible that the fix you made (perhaps has something to do with the wrapper?) somehow broke the command line parser or the serial port configuration?

Edit: Another question, with what IDE and version do you develop the code? Is that Qt Creator? Cause that way I could have a look at what is happening, maybe put some logging messages and figure out the problem. If you won't mind.

[thirtythreeforty]

Hey, sorry for the radio silence. I've been busy with school. Yeah, I probably broke something when I "fixed" those other bugs, heh... I just need to sit down and figure out what, which I will do over Christmas.

I'm using Qt Creator with MSVC 2013 and Qt 5.4 to build the things I'm sending you, and that's what was used to build the 0.8.1 release. If you can figure out what is going on, that would be fantastic. All the code I've compiled and sent to you has been pushed to GitHub, so you can just download master and start hacking. (The beauty of open source!)

[vidavidorra]

Thanks for the reply, don't worry about the 'radio silence'. :wink:
It took me some time to be able to build and run the script. Had to alternate the Build.bat, but I've got the build working now.
I also found what commit caused this behaviour. Commit 396795f has caused this 'issue'. When removing the , true again it works fine.

I still have to look a bit deeper in what this boolean does exactly (I know it does rethrow errors), but I don't have time for that right know. The arguments are correctly passed to the main exe and the portname is set correctly. And, as far as I know, the error is thrown by

void QtPicDriver::openSerialPort()

I've also checked the 'wrong' command line order using the build I made from the latest source code, and the argument order issue seems to be fixed.

[thirtythreeforty]

OK, easy enough to fix. The openSerialPort() call in the constructor shouldn't be there. The reason that was wrong is that it would try to initialize the serial port "", because there was no way for main to have set the serial port name. This of course would fail and throw an exception. Previously, the exception wasn't thrown, so when it was set by main just one line later, everything still worked.

Thanks for the hint. Can you rebuild it, or do you want me to send you another build?

[vidavidorra]

Thanks for the explanation. I've rebuild it and it is indeed working perfectly now. When I give the correct port as argument it programs it normally, and when giving the wrong COM port as argument it throws an error. Also the command line order does not matter any more in this build. So this issue can be closed.
However I was able to build it, I still need to have the following dll's in the executable dir. How do you make the .exe files without the need of these dll's? I've just ran the build.bat script since I'm on Windows.

Qt5Core
Qt5Gui
Qt5Network
Qt5SerialPort
Qt5Widgeds

[thirtythreeforty]

Very good! I'll close this then.

As far as the DLLs, I'm using a static version of Qt. Essentially that means the compiler includes the needed parts of the libraries you mention directly in the final executable. The advantage is of course that I can distribute a single binary with no DLL dependencies. I can also use UPX to compress the executable to around 40% of its original size. The downside is that I have to compile that static version of Qt myself, which is a rather large pain. The README has some details on doing that, but if you're not familiar with building Qt from source, you will probably have a frustrating time... I don't recommend bothering unless you plan to redistribute your changes. For personal use, copying DLLs around is definitely easier.

[vidavidorra]

Haha ok, thanks for the info. I'm currently writing a visualisation program with Qt for my 8x8x8 RGB LED cube and am planning on releasing that program, sometime when it's done. For now I'll just stick with the DLLs!