Hello,
I am really excited to get started with ChibiOS. However, I am having some trouble getting it running on my board (the MCHCK).
To the best of my understanding, the ChibiOS/demos/KINETIS/RT-MCHCK-K20-GPT demo should produce a program that will make the MCHCK LED blink. I've tried loading the produced binary to the offset specified by the bootloader (0xc00) but it bricks the bootloader rather than blinking. One of the MCHCK creators speculated that the ChibiOS linker files may have produced a binary that failed to compensate for the bootloader offset, so I also tried loading it to 0x0. This also failed to blink.
I don't really have an in-depth understanding of linker files or ChibiOS (I am hoping to work on the latter once I have it working on a board). If I may ask, would you give some pointers on what I should try next? Is my understanding of the intended purpose of the RT-MCHCK-K20-GPT correct? Does anyone know if the linker is taking the bootloader offset into account?
Thanks,
Charlie West
MCHCK support
Moderator: utzig
-
- Posts: 38
- Joined: Sat Jan 10, 2015 10:12 pm
- Has thanked: 1 time
- Been thanked: 1 time
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: MCHCK support
Hi Charlie,
Writing to address 0x0 should work. Not sure why it doesn't. Sadly I don't have a MCHCK to test...
The bootloader seems to be this one here:
https://github.com/mchck/mchck/tree/master/bootloader/usb-dfu
And it seems to loader the app from address 0xc00 as you mentioned. I made some small modifications to the linker script and you can overwrite the current os/common/ports/ARMCMx/compilers/GCC/ld/MK20DX128.ld with the content from this Gist:
https://gist.github.com/utzig/b2c1463f65f33085d5e2.
If your CPU doesn't have 128k of flash you might have to change the line "flash: org = 0x00000c00, len = 128k - 0xc00" with the correct size.
Another thing that could be wrong is the clock calculation. The schematics seems to be this one here: https://raw.githubusercontent.com/wiki/mchck/mchck/gen-images/mcu-MCU.png. The current code uses FEI mode or internal clock so there should be no problem but there could be...
Best approach would be to tackle this step by step. I suggest you try the linker script above and reply with your results first. It should at least not brick the bootloader.
Cheers,
Fabio Utzig
Writing to address 0x0 should work. Not sure why it doesn't. Sadly I don't have a MCHCK to test...
The bootloader seems to be this one here:
https://github.com/mchck/mchck/tree/master/bootloader/usb-dfu
And it seems to loader the app from address 0xc00 as you mentioned. I made some small modifications to the linker script and you can overwrite the current os/common/ports/ARMCMx/compilers/GCC/ld/MK20DX128.ld with the content from this Gist:
https://gist.github.com/utzig/b2c1463f65f33085d5e2.
If your CPU doesn't have 128k of flash you might have to change the line "flash: org = 0x00000c00, len = 128k - 0xc00" with the correct size.
Another thing that could be wrong is the clock calculation. The schematics seems to be this one here: https://raw.githubusercontent.com/wiki/mchck/mchck/gen-images/mcu-MCU.png. The current code uses FEI mode or internal clock so there should be no problem but there could be...
Best approach would be to tackle this step by step. I suggest you try the linker script above and reply with your results first. It should at least not brick the bootloader.
Cheers,
Fabio Utzig
-
- Posts: 38
- Joined: Sat Jan 10, 2015 10:12 pm
- Has thanked: 1 time
- Been thanked: 1 time
Re: MCHCK support
Hey Fabio,
Thank you for helping out with this.
I tried the modified linker script. When the binary produced was loaded to 0xc00, it did not appear to work. The chips that I am using have 32K rom and 8K ram. I tried a several variations of your linker script, but none of them produced a blink behavior.
I tried changing the rom size by modifying the "flash : org = 0x00000c00, len = 128k - 0xc00" line to "flash : org = 0x00000c00, len = 32k - 0xc00". That did not appear to fix it. I also tried changing both that and the ram size to 8k. This also did not produce the desired behavior.
I noticed that your linker script left out the
"flash0 : org = 0x00000000, len = 0x100
flashcfg : org = 0x00000400, len = 0x10",
so I also tried using that with the appropriate offsets. It did not produce the desired behavior.
The MCHCK linker script appears to use the following for its ram address:
"ram (rwx) : ORIGIN = 0x20000000 - 8K / 2, LENGTH = 8K"
Calculating that out would appear to result in a ram address of 0x1FFFF000, which is slightly different. This also didn't work, however.
The relavent part of the last linker script I tried is below. I have soldered several MCHCKs and would be happy to send one to you if you would like. You could send your address to my email and I can send it relatively soon (crwest@ncsu.edu). I'm currently flashing mine with a Bus Pirate, but I can make sure the bootloader is loaded and working if you don't have access to a programmer (bricking it is possible, however).
Thanks,
Charlie
MEMORY
{
flash0 : org = 0x00000c00, len = 0x100
flashcfg : org = 0x00001000, len = 0x10
flash : org = 0x00001010, len = 32k - 0x1010
ram : org = 0x1FFFF000, len = 8k
}
Thank you for helping out with this.
I tried the modified linker script. When the binary produced was loaded to 0xc00, it did not appear to work. The chips that I am using have 32K rom and 8K ram. I tried a several variations of your linker script, but none of them produced a blink behavior.
I tried changing the rom size by modifying the "flash : org = 0x00000c00, len = 128k - 0xc00" line to "flash : org = 0x00000c00, len = 32k - 0xc00". That did not appear to fix it. I also tried changing both that and the ram size to 8k. This also did not produce the desired behavior.
I noticed that your linker script left out the
"flash0 : org = 0x00000000, len = 0x100
flashcfg : org = 0x00000400, len = 0x10",
so I also tried using that with the appropriate offsets. It did not produce the desired behavior.
The MCHCK linker script appears to use the following for its ram address:
"ram (rwx) : ORIGIN = 0x20000000 - 8K / 2, LENGTH = 8K"
Calculating that out would appear to result in a ram address of 0x1FFFF000, which is slightly different. This also didn't work, however.
The relavent part of the last linker script I tried is below. I have soldered several MCHCKs and would be happy to send one to you if you would like. You could send your address to my email and I can send it relatively soon (crwest@ncsu.edu). I'm currently flashing mine with a Bus Pirate, but I can make sure the bootloader is loaded and working if you don't have access to a programmer (bricking it is possible, however).
Thanks,
Charlie
MEMORY
{
flash0 : org = 0x00000c00, len = 0x100
flashcfg : org = 0x00001000, len = 0x10
flash : org = 0x00001010, len = 32k - 0x1010
ram : org = 0x1FFFF000, len = 8k
}
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: MCHCK support
I'll try to flash the MCHCK bootloader on my Freedom K20 tomorrow and see if I can make it work and find out what's happening.
Btw, I'm subscribed to nerds@mchck.org so I'll follow the discussion you started there!
Cheers,
Fabio Utzig
Btw, I'm subscribed to nerds@mchck.org so I'll follow the discussion you started there!
Cheers,
Fabio Utzig
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: MCHCK support
Has the vectors table been relocated? there is an option to setup in the port layer.
Giovanni
Giovanni
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: MCHCK support
Charles,
I guess the option Giovanni is mentioning is CORTEX_VTOR_INIT. Of course I didn't know that!
So what happens is that os/rt/ports/ARMCMx/chcore_v7m.h reassigns the place of the vectors (SCB->VTOR = CORTEX_VTOR_INIT) so, of course, it world not work without updating this define too...
I guess the simplest way would be to add it to your demo project's Makefile like this:
Please try that and report your results.
Cheers,
Fabio Utzig
I guess the option Giovanni is mentioning is CORTEX_VTOR_INIT. Of course I didn't know that!
So what happens is that os/rt/ports/ARMCMx/chcore_v7m.h reassigns the place of the vectors (SCB->VTOR = CORTEX_VTOR_INIT) so, of course, it world not work without updating this define too...
I guess the simplest way would be to add it to your demo project's Makefile like this:
Code: Select all
UDEFS = -DCORTEX_VTOR_INIT=0x00000c00
Please try that and report your results.
Cheers,
Fabio Utzig
-
- Posts: 38
- Joined: Sat Jan 10, 2015 10:12 pm
- Has thanked: 1 time
- Been thanked: 1 time
Re: MCHCK support
Hey Fabio/Giovanni,
I tried the "UDEFS = -DCORTEX_VTOR_INIT=0x00000c00" line at the top of my make file. It did not seem to work (I tried it with 3 of the more probable linker files).
Thanks,
Charlie
P.S.
Are you sure you don't want me to send you a MCHCK?
I tried the "UDEFS = -DCORTEX_VTOR_INIT=0x00000c00" line at the top of my make file. It did not seem to work (I tried it with 3 of the more probable linker files).
Thanks,
Charlie
P.S.
Are you sure you don't want me to send you a MCHCK?
-
- Posts: 359
- Joined: Sat Jan 07, 2012 6:22 pm
- Location: Brazil
- Has thanked: 1 time
- Been thanked: 20 times
- Contact:
Re: MCHCK support
charlesrwest wrote:I tried the "UDEFS = -DCORTEX_VTOR_INIT=0x00000c00" line at the top of my make file. It did not seem to work (I tried it with 3 of the more probable linker files).
Oh no, I don't think that is a good idea. There's already a UDEFS in the last page of the Makefile which will probably overwrite the one you put in the top. You should just updated the current definition. It may also be useful to update the UADEFS definition with the same value (not sure it would be required).
You can compile with "make USE_VERBOSE_COMPILE=yes" which will provide the real gcc output so that you can review if the options are really added...
charlesrwest wrote:Are you sure you don't want me to send you a MCHCK?
Well, I don't suppose you want to wait 2 months to get ChibiOS running?
What's the exact model of the MCU on your board?
Cheers,
Fabio Utzig
-
- Posts: 38
- Joined: Sat Jan 10, 2015 10:12 pm
- Has thanked: 1 time
- Been thanked: 1 time
Re: MCHCK support
Hey Fabio,
Apologies for the delay. I just tried sticking the option at the bottom of the make file and used the make option you mentioned to confirm that it was set. With the second linker script I tried, IT BLINKS!!!!
Here is the linker script I used (a modified form of the original, with the 2 extra rom sections that the original script had):
https://drive.google.com/file/d/0B3SV9- ... sp=sharing
And here is the make file (which pretty much just has the option added at the bottom):
https://drive.google.com/file/d/0B3SV9- ... sp=sharing
And since the MCHCK page doesn't really cover how to flash an arbitrary binary without using their build system (yet), here is the command I used to load the binary with my bus pirate to the reccommended 0xc00 offset:
ruby $MCHCKBaseDirectory/programmer/flash.rb name=buspirate:dev=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6026RY1-if00-port0 ./ch.bin 0xc00
Thank you so much for your help! I'm really looking forward to getting started with ChibiOS.
P.S.
If I may ask, what is the proper procedure to get the required changes merged back into the ChibiOS source tree so that people with MCHCKs can use ChibiOS with the bootloader out of the box?
Apologies for the delay. I just tried sticking the option at the bottom of the make file and used the make option you mentioned to confirm that it was set. With the second linker script I tried, IT BLINKS!!!!
Here is the linker script I used (a modified form of the original, with the 2 extra rom sections that the original script had):
https://drive.google.com/file/d/0B3SV9- ... sp=sharing
And here is the make file (which pretty much just has the option added at the bottom):
https://drive.google.com/file/d/0B3SV9- ... sp=sharing
And since the MCHCK page doesn't really cover how to flash an arbitrary binary without using their build system (yet), here is the command I used to load the binary with my bus pirate to the reccommended 0xc00 offset:
ruby $MCHCKBaseDirectory/programmer/flash.rb name=buspirate:dev=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6026RY1-if00-port0 ./ch.bin 0xc00
Thank you so much for your help! I'm really looking forward to getting started with ChibiOS.
P.S.
If I may ask, what is the proper procedure to get the required changes merged back into the ChibiOS source tree so that people with MCHCKs can use ChibiOS with the bootloader out of the box?
Last edited by charlesrwest on Tue Jan 13, 2015 7:19 pm, edited 1 time in total.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: MCHCK support
charlesrwest wrote:If I may ask, what is the proper procedure to get the required changes merged back into the ChibiOS source tree so that people with MCHCKs can use ChibiOS with the bootloader out of the box?
Hi, just contact the maintainer of the code/port/subsystem or post your contribution in the right forum for discussion. Depending on the contribution kind/impact it will go in the main repository or in the community repository.
Giovanni
Who is online
Users browsing this forum: No registered users and 4 guests