chipKIT® Development Platform

Inspired by Arduino™

chipKIT bootloader update sketch

Created Mon, 22 Oct 2012 04:25:31 +0000 by KeithV

KeithV

Mon, 22 Oct 2012 04:25:31 +0000

For the most part the bootloaders for the older chipKIT boards have predominately remained unchanged since their inception. However advances have been going on to support features for the newer boards and substantial modifications have been made to the bootloader over time. One of our concerns is how we would update the older boards to the newer bootloader so that everyone can take advantage of these improvements. To date the only way to update a bootloader was to program it via MPLAB or MPLAB-X and use some sort of a hardware programmer such as the PICkit3, licensed debugger or chipKIT programmer.

What I have created here is a bootloader update sketch. It is a simple sketch that when run will update your bootloader. Attached is a zip file of my first cut sketchs that will update the Uno32 or Max32 to version 0x01000108 of the bootloader. I know, what does a version number mean when we never have had version numbers before? Well, let’s just say this is a starting point for bootloaders with version numbers. Here are some of the features that this bootloader provides over the original bootloaders.

  1. Dramatic code reduction. The original bootloaders ran around 7k in size, these are under 3K. As a practical matter this enabled us to make UART bootloaders for the MX1&2 which only have 3K of bootflash.
  2. Persistent Data support. In the past when the bootloader ran it cleared RAM including the sketches persistent data. This bootloader reserves at least 512 bytes of untouched RAM for persistent RAM usage. What this means is, if you put less than 512 bytes in the persistent data section, the bootloader will not wipe it out.
  3. Added Header information. As a combination of new linker scripts that you will find in MPIDE mpide-0023-xxxx-20121013 or newer and this bootloader you can get version, vendor, product, capabilities, and more information about the bootloader. When you are done updating your bootloader, go ahead and run the ViewHeaderInfo sketch and you will see all of the info available to describe the current version of MPIDE and bootloader you are running. If you do not install a new enough MPIDE, this sketch will not compile; it requires new tables added by the new linker scripts and symbols added by MPIDE.
  4. In the bootloader we fixed that the bootloader will wait for the last transmit to complete and then shuts down the UART before transferring control to the sketch. An example of how this works better, you may have noticed when uploading from mpide-0023-xxxx-20121013 that your upload may hang. This is because a delay was inadvertently removed from the sketch’s initialization code (MPIDE provided) and the bootloader did not have a chance to ensure the last byte was sent back to avrdude to say it was done. As a result avrdude does not terminate and MPIDE appears to hang during the upload. In this bootloader, before control is transferred from the bootloader to the sketch, the bootloader waits for the last byte to be sent to avrdude and then disables the UART. Thus ensuring the completion of communication with avrdude before transferring control to the sketch. If you are experiencing this problem, you can install this bootloader and you will work with mpide-0023-xxxx-20121013! But don’t worry, that delay that was removed, it will be put back to ensure older bootloaders continue to work.
  5. The new bootloader does Just-in-time, or on-demand page erases. What this means is, only the pages that are being written to are being erased; and only being erased immediately before the 1st byte is written to the page. This has its advantages of being faster to program and easier on the flash wear-out characteristics.
  6. It includes a page erase check and retry. Through some tests it was found that if a worn page does not erase on a first attempt, a second erase very likely will succeed. This bootloader will make up to 5 attempts to erase the flash before aborting the effort. Preliminary tests indicate that this will typically double the usable life of the flash.
  7. Fixed the config bits on some really early bootloaders that incorrectly specified the FMIIEN = MII instead of RMII configuration.
  8. This codebase enabled the basis for the MX1&2 UART and USB bootloaders. We also added the ability to have split-flash bootloaders where some code resides in boot-flash, and some resides in program-flash. You will find that the MX2 USB bootloaders employ the split-flash bootloaders as the USB code was too large to fit in the 3K of bootflash. Please understand that the Uno32/Max32 have 12K of bootflash and are UART bootloaders, so these bootloaders are not split-flash bootloaders.

And there are even more things that have been done, but I think my point has been made that there have been many changes. To get all of the new features you must use mpide-0023-xxxx-20121013 or newer. However, any version of bootloader will work with any version of MPIDE (with the exception of point 4 above; and that will be fixed). You just may not get the header info or bootloader feature, but the sketch will still load and run.

Okay, how to run the update sketch.

  1. In order to run this you must have a serial monitor attached (and set to 9600 baud). Also if you don't have the new bootloader already installed (which you don't if you are updating), you probably hang when uploading from mpide-0023-xxxx-20121013, to update an old bootloader you will need to install mpide-0023-xxxx-2012818 as mpide-0023-xxxx-20120903 will not compile the update sketch; but 818 will and your old bootloader can update from 818. However, once you install the new bootloader, you can then move to mpide-0023-xxxx-20121013 and you will pick up all of the new features and uploading from MPIDE will work fine. I would recommend moving to mpide-0023-xxxx-20121013 once the new bootloader is installed.
  2. Build either the Uno32 or Max32 sketch appropriate for your board. When run, the update sketch will ask you to type into the serial monitor input the board you are updating. The sketch will print out exactly what you need to type in, and you must type it in exactly as shown including the case or the sketch will abort. The reason for this is because the update sketch cannot determine exactly what board you have plugged in and if you put the wrong bootloader on the wrong board, you will have to use MPLAB to reprogram a functional bootloader. So this gives you a last chance to verify that you have the correct board attached. If you accidently programmed the wrong update sketch, just upload the right one, or a different sketch to wipe out the wrong update sketch from your chipKIT.
  3. Do not remove power or reset once the process gets started (after you have entered the board name in the serial monitor). There are 3 critical sections that if the process stops you will be required to get MPLAB to reprogram a functional bootloader. I have kept these windows extremely short, but there is a slim possibility that you will hose yourself if you pull power or reset at the wrong time. In general, if you reset the process during the update, the update will just restart; and usually this will be successful as long as you did not do this during one of the 3 critical sections. These critical sections are unavoidable, there are when, I erase the first page (the reset code), when I erase the config bits, and when I do the final linkage of the new bootloader to the reset address.
  4. You can run the ViewHeaderInfo sketch before and after you update the bootloader to see what changed in the header information. This sketch if for information only and is not required as part of the update.
  5. If anything goes wrong you can get your original bootloader off of the Digilent Web site, but you will need MPLAB and a hardware programmer to reprogram a functional bootloader. So if you are even the least bit concerned about updating, wait until you have access to a hardware programmer before using this sketch.
  6. Okay, this is beta code and I am looking for feedback as to what you think. However, the bootloader you get is code we have been running for a while now; so the bootloader is good.

I have updated the zip file in the post to the most current zip file.

KeithV

Tue, 23 Oct 2012 22:35:51 +0000

I made bootloader update sketches for the following boards:

Uno32 Max32 uC32 MX3cK MX4cK MX7cK FurbarinoSD

There are some differences in the update sketch code from the one I posted before, but the installed bootloader is the same, version 0x01000108.

This code will only compile on mpide-0023-xxxxx-20120818(9) and mpide-0023-xxxxx-20121013; it will NOT compile on mpide-0023-xxxxx-20120903.

And unless you have a new bootloader, it will only upload on mpide-0023-xxxxx-20120818(9); so really you should use 818 of MPIDE to update your bootloader. Once you have an updated bootloader, the new bootloader will work with mpide-0023-xxxxx-20121013.

pito

Sun, 28 Oct 2012 12:03:27 +0000

Hi, is there a new bootloader (.hex) for the Fubarino SD 795H version available? Thanks, p.

EmbeddedMan

Sun, 28 Oct 2012 15:22:09 +0000

Pito,

Yes, there is. I will have it available shortly, as soon as Keith gets me the latest source code for the bootloader project(s). Note that the bootloader that came on your FubarinoSD from SeeedStudio is almost exactly the same as what Keith is posting here - I'm not quite sure of the differences yet, but they are very minor.

*Brian

BloodyCactus

Mon, 29 Oct 2012 00:55:08 +0000

how does one get a bootloader onto a chip that does not have one that speaks stk500v2 ?? whatever bootloader mplabx puts on my chips does not seem to talk to mpide...

EmbeddedMan

Mon, 29 Oct 2012 01:19:41 +0000

A blank part (either blank as they come from Microchip, or blank because they were just erased) will have no bootloader on it and will not be able to be programmed by MPIDE (avrdude).

So you need to program a bootloader onto the PIC32 before it will work with MPIDE. You need a hardware programmer and MPLAB X or MPLAB 8 in order to program a blank chip with the bootloader HEX file.

Make sense?

*Brian

BloodyCactus

Mon, 29 Oct 2012 01:37:35 +0000

yep. ;) its a chicken and egg, since I dont have a hex file for the MX250F128B... I built the bootloader sketch in mpide and used mplabx to drop the hex file on but despite uploading it to the chip, did not seem to do anything. I dont have any other bootloader hex files to drop on so.. I'm kinda SOL right now.

I have the digilemt pgmr coming next week, so hopefully I'll figure some what of getting a viable bootloader onto my microstickii + breadboarded MX250's...

EmbeddedMan

Mon, 29 Oct 2012 11:58:37 +0000

If you have the programmer, then your problem will be completely solved. That programmer is a hardware ICSP programmer, and can program any PIC32 chip 'from scratch' (i.e. erased state). That's the ticket.

There has been talk of making an MPIDE sketch that would act as a (very slow) ICSP programmer for another PIC32 part. But you still have the problem of needing the first PIC32 to be programmed with a hardware programmer.

*Brian

BloodyCactus

Mon, 29 Oct 2012 14:05:10 +0000

Is there a sketch for the mini like for all the other boards. The mini is the only one not in the zip file.

My thinking is if I can build the sketch for the MX250F, I can upload it via mplabx, once I remove some the input checking etc.

zulucat

Mon, 29 Oct 2012 16:08:27 +0000

I have a couple of questions about the new boot loader:

  1. Will it work with Official Release 20120903 MPIDE?

  2. Can I burn the boot loader using MPLAB and a PICkit3?

Thanks - Doug

EmbeddedMan

Mon, 29 Oct 2012 16:57:05 +0000

Is there a sketch for the mini like for all the other boards. The mini is the only one not in the zip file. My thinking is if I can build the sketch for the MX250F, I can upload it via mplabx, once I remove some the input checking etc.

We are currently working through one remaining issue with the Mini in order for the 'update your bootloader using a sketch' sketch to work properly. We hope to have it resolved in the next couple days.

But I'm curious why you would need this sketch. If you have a FubarinoMini already, then you have a bootloader on it that is almost exactly like the one Keith has in the zip files above. Do you need to re-program you Mini with a fresh bootloader?

If you are simply trying to take a bootloader and put it on a blank MX250, then the 'update your bootloader using a sketch' sketch won't do you any good, since you have a blank chip and need to get a bootloader on there for the first time.

I think you may be confusing what Keith is talking about above (sketches that allow you to update an already existing bootloader on a board) with the botloader HEX files (and associated MPLAB 8/MPLAB X projects).

*Brian

EmbeddedMan

Mon, 29 Oct 2012 17:21:51 +0000

I have a couple of questions about the new boot loader:

  1. Will it work with Official Release 20120903 MPIDE?
  2. Can I burn the boot loader using MPLAB and a PICkit3? Thanks - Doug

  1. Yes, the new bootloader work work with 20120903, as well as all other MPIDE releases. It does not change any of the 'core functionality' that avrdude needs.

  2. Yes! That is exactly the right thing to do. MPLAB 8 or MPLAB X. Either works.

*Brian

BloodyCactus

Mon, 29 Oct 2012 17:42:19 +0000

I think you may be confusing what Keith is talking about above (sketches that allow you to update an already existing bootloader on a board) with the botloader HEX files (and associated MPLAB 8/MPLAB X projects). *Brian

yeah I have bare MX250's, and the mini was the only project using MX250's supporting by MPIDE, so I thought I could get its bootloader onto my bare chips so I could use them in MPIDE.

The stumbling block is getting a MPIDE compatible bootloader onto the chip.

MPLABX can program the chips just fine, I was just hoping to enable MPIDE as well which would have been nice :)

I was hoping, since the update bootloader sketch puts a new mpide bootloader on, I could build the sketch in mpide which creates the hex file for avrdude, then using MPLABX I can load the hex file onto the chip which would allow it to run the first time updating the bootloader. (that was my untested plan at any rate.)

I have bare MX250's breadboarded, and I also have the microchip Microstick II which is a very nice little MX250 dip board, which I added the 6 pin programming cable header to (which is really a 3 pin rs232 compat header), I wanted to get MPIDE working with the Microstick II.

From what I see, I think I should just give up on MPIDE at this point and my bare MX250's and just program them in MPLABX.

EmbeddedMan

Mon, 29 Oct 2012 18:02:42 +0000

BC,

Sorry, I must be really dense. I'm still not seeing clearly what you are trying to do.

If you have the HEX file already for a bootloader for the board you have, you can program that HEX file onto the bare chip (MX250 in your case) with any tool that is an ISCP programmer. That includes MPLAB (X or 8) plus a supported hardware programmer (like PICkit3, RealICE, ICD3, etc.)

Once you have the bootloader on the board, then you don't need MPLAB anymore and can use MPIDE to program your sketches onto the board.

You can NOT use MPIDE to program a blank chip. There is currently no way to do that, as you need a hardware programmer, and MPIDE does not talk to any hardware programmers at this point.

So if you're just looking for the FubarinoMini bootloader HEX file so that you can use a PICKit3 + MPLAB to program it into your blank 250 chips, then you can find it here : (note, location to move eventually) ([url]https://github.com/EmbeddedMan/PIC32-avrdude-bootloader/blob/master/bootloaders/chipKIT-Bootloaders/dist/MX2_FB_MINI_USB/production/chipKIT-Bootloaders.production.hex[/url])

Now, if you have the Microstick II board, I believe you can use it to program any blank MX1/MX2 chip, correct? So you can take the HEX file from the above link, and use MPLAB and your MSII to program blank chips.

*Brian

BloodyCactus

Mon, 29 Oct 2012 18:23:14 +0000

Maybe I'm the dense one, I already did that (uploaded the mini hex file with mplabx).

all I get from mpide when I upload a sketch is;

avrdude: ser_recv(): programmer is not responding avrdude: stk500v2_ReceiveMessage(): timeout

repeated forever (maybe its because its 64bit linux, I built it from source last night so its current with the git repo). I have a genuine 3.3v ftdi cable on USB0.

my assumption was that it did not have a mpide compatible bootloader on it, hence when I loaded the hex it did not work as planned..

at this point I think I will just stop pestering you, since its not a real chipkit board, any failure is on my part. thank you for answers. being able to program the simple pic32 DIP chips on a breadboard with mpide would have been fantastic but I can live with mplabx instead.

EmbeddedMan

Mon, 29 Oct 2012 18:34:30 +0000

No, you should have no trouble getting it to work.

But I still detect something in what you are writing that just doesn't make sense.

So, you say you took the FubarinoMini's bootloader HEX file, and programmed it onto your MX250 chip using the Microstick II. But then you talk about FTFI cables - you don't need an FTDI cable. The Mini (and thus the bootloader build for the Mini) only uses USB directly - no serial. So you just plug a USB cable into the MX250 (with proper supporting circuitry, of course) and the bootloader on it will enumerate over USB as an an STK500 USB serial device. THEN you can program it with MPIDE over USB.

Hopefully that will help clear it up a little -

*Brian

KeithV

Mon, 29 Oct 2012 19:18:37 +0000

Yes, once programmed, all bootloaders works with all version of MPIDE (with the exception of the bug in MPIDE 1013).

Yes, you can program with MPLABv8 or MPLAB-X. Use MPLAB-X 1.41. or newer.

pito

Mon, 29 Oct 2012 19:59:03 +0000

@Brian: I've flashed BL_1_1_6..hex to fubarino, It loads the sketch, but the fprinted data are not seen on the serial monitor (or terminal). Very often I loose the connection (comX disappear). So it seems to me the switch between the bootloader and usb_serial does not work properly..

EmbeddedMan

Mon, 29 Oct 2012 20:13:03 +0000

pito,

OK, that sounds like a very different problem than what we were working on above (just trying to get some way to program a blank chip with a bootloader).

Could you post to a new thread a complete description of this problem that you are having (the issue with the serial ports) and I will try to understand the issue there and help you out.

*Brian

BloodyCactus

Tue, 30 Oct 2012 00:06:07 +0000

the bootloader on it will enumerate over USB as an an STK500 USB serial device. THEN you can program it with MPIDE over USB. *Brian

aah, ok. on the breadboard all I have is the 6 pin ft232rl usb serial cable. mpide sees the cable but wont program it, avrdude just times out. the microstick ii has usb, and it overrides ass a specific device, not a usb serial etc. so mpide does not see it.

wrong kind of usb cable/type/device :/ aaaaah. live and learn.

I guess, once the fub-mini comes out, I'll get one as I can use that to swap my dip chips in and out of.

sorry for all the confusion mate, thanks for all your help.

EmbeddedMan

Tue, 30 Oct 2012 00:34:34 +0000

Sorry! The FuarinoMini does not have the ability to program PIC32 chips, nor can you swap PIC32s in and out of it. It is also not a 'replacement' for a PIC32 DIP part (although that gives me a good idea . . . )

So the Microstick II has a USB connection to the built-in debugger/programmer hardware. The USB connector on the MSII does NOT go to the PIC32 that you have in the socket. As you learned.

Now, you could try programming the MX1 bootloader that's up on the bootloader Github repo - that one is for MX1/MX2 parts and it uses UART (i.e. FTDI) rather than USB.

*Brian

BloodyCactus

Mon, 05 Nov 2012 02:33:22 +0000

so I've found some time and I hacked on the MX1 uart bootloader, I finally got something working on MX2 with different uart pins on uart1. For some reason I cant get it to work on uart2, with the pins mapped directly to the microstick 21/22 rx/tx lines (so I cant just use the 6 pins built onto the microstickii.. must custom wire it doh! Need to check if any config bits I turned off impact uart2...)

huzzah! I stick it on with mplabx, and I get the heartbeat led, and using just the tx/rx on my ftdi cable it uploads.

avrdude says its ok, flash verified etc. all nice and sweet... but then nothing happens. so I'm not sure it loaded ok. if I reset the chip via mclr, it comes back in heartbeat mode waiting to upload.

so it seems like its not loading the app. I'm using blink as a test, but nothing seems to trigger (heartbeat led is RA0 which is pin2? I've tried using pin 0 and pin 2 for Blink.cpp and I get no results on either...) so I'm somewhat the way there.. just need to figure out whats going on.

once mpide has uploaded the heartbeat stops, and I can see thats supposed to be correct in the bootloader, but it would seem its not running the uploaded app...

here is a big ole pastebin of the upload;

http://pastebin.com/7Budfara

anyway, its nice to actually get SOMEWHERE :)

BloodyCactus

Tue, 06 Nov 2012 01:01:52 +0000

ok.. odd. I have it working on uart1 (but currently not uart2 yet).

so.. I got Blink working, but I what I dont get is;

MicrostickII has a led tied to pin2, which is RA0. In the bootloader, the code is

#define EnableBootLED()         (TRISACLR = (1 << 0))

but in Blink in MPIDE, I have to set it as Pin 5!

how does RA0 map to pin 5??

I am programming the board as a fubarinomini right now for testing so that may have something to do with it. Once I can get uart2 working to use the same pins as the microstick I may go create a variant board def etc...

I see looking at the boarddefs in the variants directory for fuabarinomini that its pins are mapped so.. doh. I guess this is for arduino compatability or something? ugh. (pencils in the ports onto the microchip pin diagram...)

EmbeddedMan

Tue, 06 Nov 2012 02:28:23 +0000

Correct. You'll need to come up with your own variants files if you don't want to use the values already in the Fubarino Mini one.

*Brian

BloodyCactus

Tue, 06 Nov 2012 03:20:49 +0000

yeah its going to be fun (NOT!) I see your going to use the 44pin qfn? since the fumini specifies all the C1-9 pins etc. I dont have any C[0-9] pins and a bunch of RA/RB pins not included too.

I might not have anything left to be useful :) for it to work in mpide

fleatech

Sun, 11 Nov 2012 23:22:14 +0000

Board: uC32 (New, just purchased) Sketch: UpdBluC32 MPIDE: mpide-0023-windows-20121013-test Verify: OK Upload: ok UpdBluC32 Response:

UpdBL Digilent Inc, 2012

Existing bootloader version: FFFFFFFF Updating to bootloader version: 1000108

Please comfirm that you are updating the "chipKIT uC32". If this is the board you are updating enter "chipKIT uC32" exactly in the serial monitor input window. This update is for the chipKIT uC32; and it appears you are trying to update a chipKIT Uno32 Update is aborted. Program Halted

Question: Why?

KeithV

Mon, 10 Dec 2012 03:26:01 +0000

chances are you selected the Uno32 as the build board in MPIDE, you need to pick the uC32.

philippel13

Fri, 18 Jan 2013 15:28:04 +0000

hi,

i've tried to use the bootloader update sketch but i've errors on compiling.

When i want to compile the ViewHeaderInfo sketch, i've the followings errors : ViewHeaderInfo.cpp:38:14: error: 'IMAGE_HEADER_INFO' does not name a type ViewHeaderInfo.cpp: In function 'void setup()': ViewHeaderInfo.cpp:63:20: error: 'pImageHeader' was not declared in this scope

And for the ViewHeaderInfo sketch, i've the followings errors : UpdBlUno32.cpp:75:14: error: 'IMAGE_HEADER_INFO' does not name a type UpdBlUno32.cpp: In function 'void loop()': UpdBlUno32.cpp:197:39: error: 'pImageHeader' was not declared in this scope UpdBlUno32.cpp:495:30: error: 'RUN_SKETCH_ON_BOOT' was not declared in this scope UpdBlUno32.cpp:495:48: error: 'executeSoftReset' was not declared in this scope

I'm using the last version of mpide.

Any idea what is wrong ?

thank you

philippe

philippel13

Sat, 19 Jan 2013 17:17:14 +0000

hi,

as i couldn't make working the update sketch, i've used a pickit3 and MPLAB for upload the new bootloader for my uno32.

But i've seen no change about the persistents datas .... I've tried all my tests discussed in this topic : http://www.chipkit.org/forum/viewtopic.php?f=19&t=1413 And none of them work for the persistent data. The data is always cleared at reset. The same for the RTC clock which is always reset at the reset of the board.

Is someone has a working example ?

thanks

philippe

KeithV

Thu, 24 Jan 2013 17:18:42 +0000

My bet is, you are running MPIDE 903 which will give you both of the problems you are having. There was a lot of work going on that we did not feel was ready for prime time and so the release build MPIDE 903 did not contain a lot of new features. However test build MPIDE 818 has some of the new stuff and 1013 has all of the new stuff. Unfortunately, your old bootloader will not work with 1013; only the new bootloader will. So somehow you have to update your bootloader before you can get the new features that are in 1013. You can either manually install the new bootloader like you did with MPLAB, or you can install MPIDE 818 and run the update sketch, and then move to 1013 to get the new features. Sorry, but my original posting had errors about 903; I did not realize that the new features in MPIDE 818 did not make it to the release MPIDE 903; thus my confusion. I have re-edited my original post to attempt to correct that error.

So install test build MPIDE 1013 using the new bootloader, and see if your features work.

philippel13

Thu, 24 Jan 2013 20:15:41 +0000

it's seems ok now ! All the problems seems resolves. The persistents data and the RTC are ok now.

I'd loaded the new bootloader with mplab and i've done my tests with the 1013 version of MPIDE.

Thanks you because for me this features was essentials.

Here is my test sketch :

#include "plib.h"

#include <Wire.h> int i; unsigned int attribute((section(".persist"))) test;

void setup() { Serial.begin(9600);

SYSKEY = 0x0; SYSKEY = 0xAA996655; SYSKEY = 0x556699AA; OSCCONSET = 2; SYSKEY = 0x0; Serial.println(); Serial.print("RTCCON= "); Serial.print(RTCCON, HEX); Serial.print(" / "); Serial.print("OSCCON= "); Serial.print(OSCCON, HEX); Serial.println(); // RTCTIME = 0;

Serial.println("RESET"); }

void loop() {

i++; test++; Serial.print(test); Serial.print('-'); Serial.println(RTCTIME, HEX); delay(1500); }

and the result :

RTCCON= 8042 / OSCCON= 1453322 RESET 630712772-10134500 630712773-10134700 630712774-10134800

RTCCON= 8042 / OSCCON= 1453322 RESET 630712775-10135100

RTCCON= 8040 / OSCCON= 1453322 RESET 630712776-10135400 630712777-10135500 630712778-10135700

KeithV

Sun, 27 Jan 2013 04:24:33 +0000

Good to hear!

You know there is a soft reset function suppored in 1013.

// Options for the SoftReset() function's 'options' parameter #define ENTER_BOOTLOADER_ON_BOOT 1 #define RUN_SKETCH_ON_BOOT 0

unsigned int executeSoftReset(uint32_t options);

Look down in

...mpide-0023-windows-20121013-test\hardware\pic32\cores\pic32\wiring.c (and .h).

philippel13

Thu, 31 Jan 2013 16:51:22 +0000

hi,

I confirm the persistent datas works well now.

I've only a little problem. I can't declare the persistent data in a .h file because it generate an error.

in the public session of an .h file : unsigned int attribute((section(".persist"))) test ;

==> error : E:\mpide\dev\libraries\serena/zones.h:56:52: error: section attribute not allowed for 'test'

When i put this same declare in the .cpp, all works well.

It is not a blocking problem but it will be better for me to dclare in a .h file ....

An idea for resolving this problem ?

philippe

KeithV

Sat, 09 Mar 2013 00:30:05 +0000

I think you can only declare data allocation in one file. you would have to do an extern in the header file (or the implied extern). So you can only put the persistent attribute in a .cpp file somewhere, and then in the header just put

extern unsigned int test ;

see if that works. If not, ask JasonK he is the compiler expert.

drbender

Mon, 11 Mar 2013 20:14:03 +0000

@KeithV

many thanks for your post and the bootloader update sketch.

i am new to the Uno32 and dealing with the easydriver and the AccelStepper library for my cnc hotwire project.

All my uploads with the official mpide release on win7 64bit build went wrong and the stepper didn't run. the beta release dropped sometimes funny errors when i tried to upload the sketch (serial port in use; upload hangs; nothing happend at all).

Luckily i found your posting about the chipKIT boatloader update sketch. now everythings runs smooth and free of errors :) might be a good idee to keep this topic sticky for all new users to the chipKIT.

with kind regards

drbender

ddman119

Mon, 17 Feb 2014 16:45:19 +0000

@KeithV

Could you post a link where one could get mpide-0023-xxxxx-20120818(9)?

I have the problem you have specified earlier on in this post. My board is a Cerebot MX7CK and I am currently out of options without a hardware bootloader such as PICKIT3.

Running your bootloader code for this specific version of mpide with the in-circuit programmer, will it fix this problem of my uploader hanging? My avrdude.exe does indeed hang since i've checked my task manager even while using the latest version of mpide (mpide-0023-windows-20140121-test)...