chipKIT® Development Platform

Inspired by Arduino™

Serial enabled hex file for olimex pinguino micro

Created Tue, 03 Nov 2015 09:52:59 +0000 by captainSpark

captainSpark

Tue, 03 Nov 2015 09:52:59 +0000

Hi There,

I'm working on a project where I would like to upload code to my Olimex Pinguino Micro using a wireless serial connection. The connection works very well with 57600 baudrates and i have this working programming a bunch of Arduino pro mini's over large distance (400meters). The project is about a lighting artpiece, where the MCU will send DMX signals over to 72 lights. The tricky part is this thing will be in the middle of the water.... so not so reachable.. I would like to be able to reprogram the sequences and calculations from the land. For this i have a stable Serial connection at 57600 baudrate(it can go higher, but this so far works best). It is working stable with the arduino pro mini's, but they lack the power for calculation 72 lights and updating them fast enough for smooth transitions.

I opened my drawer full of unused development boards and there is the Olimex Pinguino Micro, 80Mhz!, 32Bit!, 2 uarts!, no strange 1200 baudrates to reset the bootloader! Everything i need for my application... whoho, no let’s fire this thing up! I did not use this board yet, so i needed to do a bit off research and found that the MPIDE seemed like the best choise. On the Olimex site is a library that contains the HEX file for the board and other configurations. : [url]https://www.olimex.com/Products/Duino/PIC32/PIC32-PINGUINO-MICRO/resources/MPIDE_library_PIC32-Pinguino-Micro.zip[/url] ! alert direct download link.

Then I followed the instructions to upload a bootloader using a picKit3. [url]http://chipkit.net/tag/bootloaders/[/url] Wow great success! Little fiddling and the bootloader works with the MPIDE, i was uploading the blink sketch and this was working as expected.

That’s great and all, but i want to upload using a serial connection preferably at 57600 baudrate. I could not find the appropriate HEX file for this. So using the files found here: [url]https://github.com/chipKIT32/PIC32-avrdude-bootloader[/url] I thought I could compile that HEX myself. Now I’m not a complete idiot in programming, but I never used the MPLABX before so it took a little work to understand what is happening.. At current I think i have configured the files in a way that it should output the correct HEX.. However i'm really not sure, running out of time and i can't compile because I only have a free compiler.... so therefore I hope someone can help me out here.

I was hoping someone could help me compiling a Bootloader Hex file for the Olimex Pinguino Micro, so it can be programmed with a Serial Connection at a speed of 57600 baud?

Thanks!

EmbeddedMan

Tue, 03 Nov 2015 13:27:25 +0000

Captain,

I'm more than happy to help. I can compile the bootloader for you.

I've added a Pinguino UART 57600 configuration to the bootloader repo. However, I must be missing some little thing, as it doesn't quite compile yet. I have to leave for work now, but I'll check it out when I get home.

If you want to take a look and make sure that my modifications are as you expect, that would be helpful.

*Brian

EmbeddedMan

Tue, 03 Nov 2015 13:32:42 +0000

Captain,

Sorry, there's another change that's being made to the bootloader at present, so I have to update my Pinguino 57600 before it will make it into the repo. I'll try to do these changes tonight and get you a hex file to test.

*Brian

captainSpark

Tue, 03 Nov 2015 16:06:03 +0000

Hia Brian,

Wauw thats really nice, thanks. Look forward to test the file.

majenko

Tue, 03 Nov 2015 19:30:43 +0000

I know Brian's out at the moment and has started on this, but I have been working on a new compilation system for the bootloader that doesn't use MPLAB-X, so I have knocked up a bootloader that might work. I don't know if it will or not, but you're welcome to try it.

It's set to use the UART 2, which looking at the schematics is what is linked to the UEXT header on the Micro, and running at 57600 baud. I don't have one of these boards to test it on, so let me know if it works or not.

captainSpark

Tue, 03 Nov 2015 21:26:04 +0000

Thanks allot.

It works when pressing reset at the right time.

I burned the bootloader with no problem. Next i tried uploading a blink sketch. The board was flashing quickly as it was ready for a upload. I uploaded the sketch trough serial and it worked. I see the set Blinking.

If I "reset" the board manual, it starts running its program quite quickly again. after a second orso. While before it was waiting for a upload indefinitely. I prefer the last mode. As i can somehow set this trough the wireless serial connection, and than upload whenever ready.

Any idea's?

Edit1: Ok if i press reset at the correct moment I can upload a sketch again. Just like with an Arduino. Could this be changed? so that it waits indefinitely(or like a minute) so i can give a reset via serial and than close to compile and send the file over?

EmbeddedMan

Fri, 06 Nov 2015 02:58:45 +0000

Captian,

I'm so glad it is working for you (almost) perfectly. Majenko is super nice for creating that version for you. Thanks Majenko!

With USB bootloaders, you have a "Program Button". You have to hold down the program button while you reset the board. That's how the bootloader knows to stay in bootloader mode until you upload your sketch.

Normally with UART bootloaders, we don't use a Program Button, because there is normally an FTDI chip on the board, and it's hardware handshake line is tied to the PIC32's reset, so that when you open up the COM port from the PC side, the FTDI chip toggles the RESET (MCLR) pin of the PIC32, and the bootloader then waits for a couple seconds for the magic values to come over the UART and then uploads from there.

If you don't have the automatic reset from FTDI chip on your board (which you don't) then you can define a Program Button in the bootloader config and build with that option enabled. Then you can attach a programming button to your board, and then it will behave as you are wanting it to (i.e. stay in bootloader mode forever until you upload a sketch).

I don't think Majenko has committed his changes for your bootloader to the bootloader repo yet, so I can't go in and make this change myself, or I'd do it for you right now.

Does that make sense? Do you want that bootloader button option enabled, and if so, on what I/O pin?

*Brian

captainSpark

Fri, 06 Nov 2015 10:51:35 +0000

Hey Embeddedman, that is indeed super nice that Majenko created that file! Also thanks for your help and clarification! so friendly, cool.

I understand the UART reset behavior and the handshake tied to the reset. I do not have a DTR line on my wireless serial. So i used a extra Arduino pro mini, which I normally connect to via Serial. I than request a reset or upload via Serial to this AVR. The AVR resets the PIC32 and holds the line low till it sees action on the serial and than release its own serial port and makes way for the Serial to the PIC. Now doing this with another Arduino Pro did not gave me any trouble, but with the PIC it seems the Serial line does not release, although i have called Serial.end(); So it would help allot if it just stays and wait for a new sketch, just by making a pin HIGH or LOW. Than i don't have to worry about finding the right timing and occupying Serial ports at the wrong time.

Otherwise thanks a million so far. edit: I actually don't know what pin would be wise, for my application it does not matter, i won't be using allot of pins, but if someone else does, i'm not so sure what to choose. Could the same pin as the button is tied to be used? [url]https://www.olimex.com/Products/Duino/PIC32/PIC32-PINGUINO-MICRO/resources/PIC32-PINGUINO-MICRO-Revision-A.pdf[/url] !alert direct download link. Page 26 shows the schematics of the board. I think pin: 52 (OC5/IC5/PMWR/CN13/RD4) It could be jumpered to another pin(in the schematic it states "closed") but this does not seem to be the deal on my board. If the button pin is used this would keep things logic I guess. as it seems the pin is broken out in connector 2 pin 3, it would also be reachable.

majenko

Fri, 06 Nov 2015 11:19:58 +0000

The bootloader also has a "virtual" programming button facility. This is an IO pin that is set into a specific state before reboot and the bootloader then checks that state to see if it is in the "enter bootloader" state. This allows you to enter the bootloader from within your sketch. It works just like a real PROG button in that it stays in the bootloader until a new firmware is uploaded or the bootloader is instructed to exit by pic32prog or avrdude.

Care has to be taken when using this method of bootloading, and having a backup, hardware, method is always a good idea, since if you upload broken firmware you can then never get back into the bootloader to upload working firmware. Also the board definition in UECIDE / MPIDE must have that virtual programming pin set in it for it to know what to do from within your sketch (unless you do it all manually in your code instead of using the normal API calls), so extra work making sure everything is synchronised properly is needed.

Brian: I thought my commits had added on to an already open PR, but I was mistaken - there was no open PR ;) I have made a new one with the configs in them. I don't use MPLAB-X any more for the bootloaders, so there is no MPLAB-X configuration entries for them, only Makefile entries.

majenko

Fri, 06 Nov 2015 11:32:57 +0000

I have set the program button and virtual program button to D4 so it should work by holding that pin LOW when the board is rebooted. Also the command:

executeSoftReset(ENTER_BOOTLOADER_ON_BOOT);

will enter the bootloader from within your sketch if you add this entry to the Board_Defs.h for the Olimex board:

#define USE_VIRTUAL_PROGRAM_BUTTON      1
#define VIRTUAL_PROGRAM_BUTTON_TRIS     TRISDbits.TRISD4
#define VIRTUAL_PROGRAM_BUTTON          LATDbits.LATD4

Alternatively you can do it manually:

TRISDbits.TRISD4 = 1;
LATDbits.LATD4 = 1;
executeSoftReset(0);

That way you don't need to modify the files.

captainSpark

Fri, 06 Nov 2015 12:35:15 +0000

Hi Majenko,

I uploaded the new HEX you gave. It does do something but not entirely what i expected.

When resetting often enough sometimes it goes into boot-loader mode. Orange led goes on and it waits for code.(i can successfully send it than.) But it seems not related to D4 or to the button. It looks more like a floating pin situation.

I did not do the in software setting, as I will not use this in the field. Do I still need to add the code though?

Edit: Ok I was not paying attention. It does wait indefinitely, despite if the orange led is coming on or not. I'm not sure what that does, but i can upload. This is great!

majenko

Fri, 06 Nov 2015 13:42:12 +0000

There are now 2 LEDs defined in this version of the bootloader - one should blink for general bootloader activity, and the other should flash as data is being received.

// Boot LED
    #define BLedLat     G
    #define BLedBit     6

    // Download LED
    #define DLedLat     D
    #define DLedBit     1

If you want to see the full config it's the first entry in this file: https://github.com/MajenkoProjects/PIC32-avrdude-bootloader/blob/master/bootloaders/configs/olimex.h

captainSpark

Fri, 06 Nov 2015 17:10:12 +0000

Works completely like you mentioned. Thanks for this!