Created Tue, 04 Dec 2012 03:56:31 +0000 by Jimstrong
Tue, 04 Dec 2012 03:56:31 +0000
Hi, any one got any clue how i could customize the uno32 bootloader to suite the PIC32MX440F512 chip? I got MPLAB ICD 3 for the programmer.
Many thanks.
Tue, 04 Dec 2012 15:35:05 +0000
I would start with the new bootloader - see here : [url]http://www.chipkit.org/forum/viewtopic.php?f=6&t=1824[/url]
*Brian
Wed, 05 Dec 2012 04:25:12 +0000
Thanks, Brian.
There are so many different versions in the new bootloader. Which one should I start with? Can I compile the specific bootloader source code with MPlab?
I would start with the new bootloader - see here : [url]http://www.chipkit.org/forum/viewtopic.php?f=6&t=1824[/url] *Brian
Wed, 05 Dec 2012 05:06:22 +0000
Well, there's actually only one bootloader. But you can configure it in a large number of ways. You can take the one configuration for the UNO32 and customize it however you like, for your own board. There are a whole bunch of configurations if you want to load the MPLAB X project, or individual projects (one for each configuration) for MPLAB 8.
If you have any questions on how to configure it, take a look at BoardConfig.h and see how we do it for the various supported boards.
*Brian
Wed, 05 Dec 2012 05:32:06 +0000
Thanks alot. EmbeddedMan.
I have checked the varoius bootloader .mcp in MPLAB 8. It seems they all share the same files, such as Boardconfig.h and main.c. So if I want to customizethe bootloader for my board, which file should I edit? I would appreciate if you could also specify which part. Thanks
Well, there's actually only one bootloader. But you can configure it in a large number of ways. You can take the one configuration for the UNO32 and customize it however you like, for your own board. There are a whole bunch of configurations if you want to load the MPLAB X project, or individual projects (one for each configuration) for MPLAB 8. If you have any questions on how to configure it, take a look at BoardConfig.h and see how we do it for the various supported boards. *Brian
Wed, 05 Dec 2012 14:31:20 +0000
The right way to do it is to create a copy of one of the MPLAB 8 projects that's closest to the board you'll be creating the bootloader for. For example the UNO32. Rename it, etc. for your board. Then go into the BoardConfig.h file, and copy/paste the UNO32 section (board you started with) and rename the copied section to your own board. You then need to set up a project based #define to turn on that section of the BoardConfig.h file. You then just tweak the settings in your section of BoardConfig.h to match your processor and board. That should do it. This is of course a overview, not a detailed guide.
*Brian
Wed, 05 Dec 2012 15:52:30 +0000
Dear Brian,
I have copied the uno32 project and add one block for my board in the Boardconfig.h with the chip PIC32MX440F512H.
In the Boardconfig.h file, I only changed the following line compared to uno32 setup. #define FLASH_BYTES 0x80000 // 512K
And I programed it.
I have two questions:
thanks.
The right way to do it is to create a copy of one of the MPLAB 8 projects that's closest to the board you'll be creating the bootloader for. For example the UNO32. Rename it, etc. for your board. Then go into the BoardConfig.h file, and copy/paste the UNO32 section (board you started with) and rename the copied section to your own board. You then need to set up a project based #define to turn on that section of the BoardConfig.h file. You then just tweak the settings in your section of BoardConfig.h to match your processor and board. That should do it. This is of course a overview, not a detailed guide. *Brian
Thu, 06 Dec 2012 00:58:30 +0000
I think that's probably it. You changed the CPU in MPLAB 8 to the 512K part, correct?
You'll know if it's working if you can download to it over the UART (however you have that set up for your board).
*Brian
Thu, 06 Dec 2012 09:35:16 +0000
Dear Brian, I have further investigated the problem, now I changed the boarConfig.h as the following:
[color=#FF0000]1. Define usb interface as I connected usb to the usb module without USB to serial [/color] #define CAPABILITIES (blCapDownloadLED | blCapUSBInterface| blCapAutoResetListening | blCapProgramButton | blCapVirtualProgramButton | CAPCOMMON)
[color=#FF0000]2. Do the virtual program button and the button has to be the same port?[/color]
#define fLoadFromAVRDudeViaProgramButton (PORTEbits.RE4 == 0)
#define fLoadFromAVRDudeViaVirtualProgramButton (LATEbits.LATE4 == 1)
#define ClearVirtualProgramButton() (LATECLR = (1 << 4))
[color=#FF4000]/BoardConfig.h:1377:6: #error Board/CPU combination not defined[/color]
Please help.
I think that's probably it. You changed the CPU in MPLAB 8 to the 512K part, correct? You'll know if it's working if you can download to it over the UART (however you have that set up for your board). *Brian
Thu, 06 Dec 2012 13:27:58 +0000
Dear Brian, I downloaded the bootloader folder and run MX4-USB.mcp. When I build all the project, the following error appears.
Executing: "C:\Program Files\Microchip\MPLAB C32 Suite\bin\pic32-gcc.exe" -nostartfiles -mdebugger -mprocessor=32MX460F512L "main.o" "crt0.o" "cdcacm.o" "usb.o" -o"MX4-USB.elf" -Os -nostdlib -mips16 -mno-float -Wl,-L"C:\Program Files (x86)\Microchip\MPLAB C32 Suite\lib",-L"C:\Program Files (x86)\Microchip\MPLAB C32 Suite\pic32mx\lib",--script="MX3-7-boot-linkerscript.ld",--defsym=__MPLAB_BUILD=1,--defsym=__MPLAB_DEBUG=1,--defsym=__MPLAB_DEBUGGER_ICD3=1,--defsym=__ICD2RAM=1,--no-check-sections,-Map="MX4-USB.map"
C:\Program Files\Microchip\MPLAB C32 Suite\bin..\lib\gcc\pic32mx\3.4.4........\pic32mx\bin\ld.exe: MX4-USB.elf: section .dbg_data vma 0xa0000000 overlaps previous sections
C:\Program Files\Microchip\MPLAB C32 Suite\bin..\lib\gcc\pic32mx\3.4.4........\pic32mx\bin\ld.exe: MX4-USB.elf: section .skip_ram_space vma 0xa0000200 overlaps previous sections
C:\Program Files\Microchip\MPLAB C32 Suite\bin..\lib\gcc\pic32mx\3.4.4........\pic32mx\bin\ld.exe: MX4-USB.elf: section .bss vma 0xa0000600 overlaps previous sections
crt0.o: In function _no_nmi': (.startup+0x0): undefined reference to
_stack'
crt0.o: In function _no_nmi': (.startup+0x4): undefined reference to
_stack'
crt0.o: In function _bss_check': (.startup+0x68): undefined reference to
_data_image_begin'
crt0.o: In function _bss_check': (.startup+0x6c): undefined reference to
_data_image_begin'
crt0.o: In function _bss_check': (.startup+0x70): undefined reference to
_data_begin'
crt0.o: In function _bss_check': (.startup+0x74): undefined reference to
_data_begin'
[color=#FF4000]Link step failed.[/color]
I think that's probably it. You changed the CPU in MPLAB 8 to the 512K part, correct? You'll know if it's working if you can download to it over the UART (however you have that set up for your board). *Brian
Thu, 06 Dec 2012 14:19:08 +0000
So if you build the MX4-USB project in MPLAB 8, without any changes, it fails to build? That's strange.
I just downloaded a fresh copy to my machine, and after setting the build tool location properly (the project, as it stands in Github right now, has the tool location specified in the project file - uncheck that from the Project->Select Language Toolset dialog box and make sure you have C32 v2.02 installed) and it built just fine for me.
Maybe it's using the wrong compiler? You need to use C32 v2.02 with this code.
*Brian
Thu, 06 Dec 2012 14:23:48 +0000
Dear Brian, I have further investigated the problem, now I changed the boarConfig.h as the following: [color=#FF0000]2. Do the virtual program button and the button has to be the same port?[/color]
Yes, I think they do. Just use whatever I/O pin your PRG button is connected to. You need a PRG button if you're using USB as your communication method back to the PC.
- In the project, I compliled main.c and it is successful. But if I [color=#40FF00]build al[/color]l by right click in the project name, it has some errors. The first one is [color=#FF4000]/BoardConfig.h:1377:6: #error Board/CPU combination not defined[/color] Please help.
Well, if you probably created a new board define for the section in the BoardConfig.h file for your board, right?
In otherwords, instead of #elif defined(BOARD_CHIPKIT_UNO32) you have #elif defined(BOARD_JIMSTRONG_BOARD)
correct?
Then you need to go into the build options and remove the existing preprocessor macro in the MPLAB PIC32 C Compiler tab and add in the new macro (BOARD_JIMSTRONG_BOARD).
See if that helps.
*Brian
Fri, 07 Dec 2012 02:15:01 +0000
Dear Brian,
after changing the C32 compile version to 2.02, I sucessfully build all the boot loader in to the PIC32MX440512H.
I have also blinked the LED via mpIDE on the board through the USB port. Many thanks.
One thing is that in this bootloader, when first powered on or reset button is pressed, the down load LED is half bright while the boot LED would blink 2-3 seconds and then goes off. After that, the real program starts to blink the LED.
A similar thing is that at power up or reset, the com port in the device manager pop up once and disappear. I need to press the reset and pull down PROG for the com port to appear.
Is this due to some setup during the bootloader?
Thanks for all your past help. I do appreciate it!
Jimstrong
Fri, 07 Dec 2012 03:36:23 +0000
Wow! That's great news. I'm really glad you got it working.
About the strange LED behavior and needing to reset - no, I don't think that's how it is supposed to be. I think there may be something wrong with the way it's detecting if it needs to be in bootloader mode or not on your board. Maybe something to do with the virtual program button? On the Fubarino SD (which is also 440 USB based) this problem does not happen.
*Brian
Fri, 07 Dec 2012 04:12:18 +0000
The LED is behavior is like this.
When I only burn the the bootloader and plug the USB to the board, it will keep in bootloader mood.
After i burn the Blink LED through mpIDE, it has the strange behavior. When power up or reset, it first stay in bootloader mode for 2-3 seconds, the begin to blink the LED.
I guess as long as I can burn program, I will live with this for now.
Thanks Brian.
Jim
Wow! That's great news. I'm really glad you got it working. About the strange LED behavior and needing to reset - no, I don't think that's how it is supposed to be. I think there may be something wrong with the way it's detecting if it needs to be in bootloader mode or not on your board. Maybe something to do with the virtual program button? On the Fubarino SD (which is also 440 USB based) this problem does not happen. *Brian
Fri, 07 Dec 2012 15:24:33 +0000
Yeah, that's not right. When using the USB bootloader, it should ONLY go into the bootloader (and thus connect to the PC as a serial port for bootloading) if you have the button pressed as you reboot, OR if the virtual button is set in software and a software reset is executed.
The "go into bootloader mode every time you are reset for 2 seconds" thing is how the USART bootloader works. Maybe you still have the UART section of code turned on?
*Brian
Fri, 07 Dec 2012 16:05:06 +0000
Brian,
I have commented the following code:
So I do not think I turned on the UART code.
The other thing is that the USB port does not connect to the UART port via FTDI cihp, it connects to the USB module directly. Will this cause some problem?
Jim
Yeah, that's not right. When using the USB bootloader, it should ONLY go into the bootloader (and thus connect to the PC as a serial port for bootloading) if you have the button pressed as you reboot, OR if the virtual button is set in software and a software reset is executed. The "go into bootloader mode every time you are reset for 2 seconds" thing is how the USART bootloader works. Maybe you still have the UART section of code turned on? *Brian
Fri, 07 Dec 2012 16:58:56 +0000
Jim,
No, that's only way it can work - a direct USB connection from the PIC32 to the PC.
Hmm. I'm not really sure why you're seeing the strange behavior.
*Brian
Sat, 08 Dec 2012 03:35:04 +0000
Now I think the LED behavior is right.
When first burn the bootloader, only one LED will blink, indicating it's in bootloader mode. Once I program the chip in via mpIED, it directly starts the programe without any strange behavior.
I have changed nothing. Very strange. But I am glad that I got it done in one week.
Thanks, Brian. Have a nice weekend.
Jim
Jim, No, that's only way it can work - a direct USB connection from the PIC32 to the PC. Hmm. I'm not really sure why you're seeing the strange behavior. *Brian