Importer doesn't use correct bootloader image for Fubarino Mini #15
Comments
|
Note this is with importer v1.0.0 |
|
Ping - any chance this could be fixed and a new importer released? This bug causes all Fubarino Mini debug sessions to result in a Fubarino Mini that is functional, but all timing related operations are off. Baud rates are not accurate, delays are not correct, etc. (Because the code things that the core is running at 48Mhz, but it's actually at 40MHz). |
|
Sure. I wanted to bundle some issues into version 1.0.1 but I guess I can fix this bug and maybe add few "enhancements". |
|
Well, if you're planning on a 1.0.1 update in the near-ish future, then
don't do a special build just for me. :-) I just want to make sure this
issue gets solved relatively quickly since people are starting to use the
importer now, and it should be very easy to solve.
…On Thu, May 4, 2017 at 12:10 PM, Grzegorz Hołdys ***@***.***> wrote:
Sure. I wanted to bundle some issues into version 1.0.1 but I guess I can
fix this bug and maybe add few "enhancements".
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCJfTLzZkXL53NptQmzJnVZkxrvNbks5r2gZ8gaJpZM4NFcW1>
.
|
|
Just committed version 1.0.1. Please verify if this issue has been successfully resolved. |
|
Unfortunately, I can no longer compile the sketch that I use to test this
with. With the v1.0.2 plugin, I get the following error on compile:
make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory 'C:/Users/Brian
Schmalz/MPLABXProjects/SPITestTransactions.X'
make -f nbproject/Makefile-default.mk
dist/default/production/SPITestTransactions.X.production.hex
make[2]: Entering directory 'C:/Users/Brian
Schmalz/MPLABXProjects/SPITestTransactions.X'
chipKIT-libraries\SPI\SPI.cpp:174:1: fatal error: opening dependency file
build/default/production/chipKIT-libraries\SPI\SPI.o.d: No such file or
directory
"C:\Program Files (x86)\Microchip\xc32\v1.43\bin\xc32-g++.exe" -g -x c++ -c
-mprocessor=32MX250F128D -IchipKIT-core -IchipKIT-libraries/SPI -frtti
-fno-exceptions -fno-check-new -fenforce-eh-specs -DF_CPU=48000000L
-DARDUINO=10613 -D_BOARD_FUBARINO_MINI_ -DMPIDEVER=16777998 -DMPIDE=150
-DIDE=Arduino -DXPRJ_default=default -D__CTYPE_NEWLIB -MMD -MF
build/default/production/chipKIT-libraries\SPI\SPI.o.d -o
build/default/production/chipKIT-libraries\SPI\SPI.o
chipKIT-libraries\SPI\SPI.cpp -DXPRJ_default=default -DARDUINO_ARCH_PIC32
-mno-smart-io -ffunction-sections -fdata-sections -mdebugger -Wcast-align
-fno-short-double -ftoplevel-reorder -MMD -G1024 -D_USE_USB_FOR_SERIAL_
-mnewlib-libc -std=gnu++11
}
^
compilation terminated.
nbproject/Makefile-default.mk:129: recipe for target
'build/default/production/chipKIT-libraries\SPI\SPI.o' failed
source\SPITestTransactions.cpp:32:1: fatal error: opening dependency file
build/default/production/source\SPITestTransactions.o.d: No such file or
directory
}
^
compilation terminated.
"C:\Program Files (x86)\Microchip\xc32\v1.43\bin\xc32-g++.exe" -g -x c++ -c
-mprocessor=32MX250F128D -IchipKIT-core -IchipKIT-libraries/SPI -frtti
-fno-exceptions -fno-check-new -fenforce-eh-specs -DF_CPU=48000000L
-DARDUINO=10613 -D_BOARD_FUBARINO_MINI_ -DMPIDEVER=16777998 -DMPIDE=150
-DIDE=Arduino -DXPRJ_default=default -D__CTYPE_NEWLIB -MMD -MF
build/default/production/source\SPITestTransactions.o.d -o
build/default/production/source\SPITestTransactions.o
source\SPITestTransactions.cpp -DXPRJ_default=default -DARDUINO_ARCH_PIC32
-mno-smart-io -ffunction-sections -fdata-sections -mdebugger -Wcast-align
-fno-short-double -ftoplevel-reorder -MMD -G1024 -D_USE_USB_FOR_SERIAL_
-mnewlib-libc -std=gnu++11
make[2]: *** [build/default/production/chipKIT-libraries\SPI\SPI.o] Error 1
make[2]: *** Waiting for unfinished jobs....
nbproject/Makefile-default.mk:135: recipe for target
'build/default/production/source\SPITestTransactions.o' failed
make[2]: *** [build/default/production/source\SPITestTransactions.o] Error 1
make[2]: Leaving directory 'C:/Users/Brian
Schmalz/MPLABXProjects/SPITestTransactions.X'
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2
nbproject/Makefile-default.mk:90: recipe for target '.build-conf' failed
make[1]: Leaving directory 'C:/Users/Brian
Schmalz/MPLABXProjects/SPITestTransactions.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
BUILD FAILED (exit value 2, total time: 287ms)
This is the sketch I used:
#include <SPI.h>
const int slaveSelectPin = 30;
char x;
static SPISettings spi_settings = SPISettings(24000000, MSBFIRST,
SPI_MODE0);
void setup() {
Serial.begin(115200);
while(!Serial)
{
;
}
delay(1000);
pinMode (slaveSelectPin, OUTPUT);
SPI.begin();
}
void loop() {
digitalWrite(slaveSelectPin,LOW);
SPI.beginTransaction(spi_settings);
SPI.transfer(x);
SPI.endTransaction();
digitalWrite(slaveSelectPin,HIGH);
delay(250);
while(1);
x++;
}
Now, one thing - MPLAB X just auto-updated may XC32 toolchain to v1.2, if
that makes a difference, I don't know. But at this point v1.0.2 of the
importer is broken for me.
The Blink sketch doesn't even build for me anymore either.
…On Thu, May 4, 2017 at 1:22 PM, Grzegorz Hołdys ***@***.***> wrote:
Just committed version 1.0.1. Please verify if this issue has been
successfully resolved.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCCULSQkSmuOqauPIETl6wJknPVvIks5r2hdggaJpZM4NFcW1>
.
|
|
The problem seems to be Windows-related. I've tried to reproduce your error on my Linux box and could not do that - no matter which mode of import I used or which configuration, the build always was successful. However, when I switched to Windows and tried to import and build your code, I immediately got the error with missing SPI.o.d. I'm still investigating this issue... |
|
You may be able to get to the root of the problem even simpler if you can
reproduce my failure to build the Blink sketch. That doesn't use any
libraries, so it should be a less complicated case . . ,
…On Fri, May 5, 2017 at 8:39 AM, Grzegorz Hołdys ***@***.***> wrote:
The problem seems to be Windows-related. I've tried to reproduce your
error on my Linux box and could not do that - no matter which mode of
import I used or which configuration, the build always was successful.
However, when I switched to Windows and tried to import and build your
code, I immediately got the error with missing SPI.o.d. I'm still
investigating this issue...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCN3fHeeh_OpkEr-5suGSmkSSCNYCks5r2yaEgaJpZM4NFcW1>
.
|
|
I confirmed that the problem is with relative paths to library and source files. When the paths are absolute, the build works fine. |
|
The problem is in the "slashes" on Windows (surprise, surprise). It turns out that MPLAB X on Windows actually expects Unix-like slashes in relative paths. When I removed the SPI files and the project source file from the project and added from the context menu, everything started to work fine. |
|
The issue with wrong slashes on Windows has been fixed in version 1.0.3 (available on GitHub and soon in plugin repository). Please verify. |
|
OK, so v1.0.3 works for me, in that it compiles and downloads just fine now. (Thank you!) However, it appears the wrong bootloader is still being used for Fubarino Mini when programming the debug build (i.e. to restore the bootloader.) It is still running the core at 40Mhz rather than 48MHz. |
|
There are two versions of Fubarino Mini: fubarino_mini_dev that uses Fubarino-Mini_USB_48MHz.hex and fubarino_mini that is mapped to Fubarino-Mini.hex. If both versions should use the 48MHz bootloader then what is the point of the other .hex file? |
|
Yeah, there's some history there. I was developing the Fubarino Mini with
40Mhz parts, because that's all that was available at the time. Right
before we went into production, Microchip came out with the 50Mhz rated
parts. We decided to go with the 50Mz versions for production, and run them
at 48Mhz (so that USB would work).
So the first bootloader (the one without a speed in its name) is set to run
on a 40Mhz part. We did make some limited numbers of 40Mhz Fubarino Minis
(by hand), so I kept that bootloader around for folks that only have 40Mhz
parts.
The 48Mhz version should be used for both types of Fubarino Mini's that are
in chipKIT core.
…On Fri, May 12, 2017 at 11:31 AM, Grzegorz Hołdys ***@***.***> wrote:
There are two versions of Fubarino Mini: fubarino_mini_dev that uses
Fubarino-Mini_USB_48MHz.hex and fubarino_mini that is mapped to
Fubarino-Mini.hex. If both versions should use the 48MHz bootloader then
what is the point of the other .hex file?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCD1rlbOVWDjLTjOXetoNP8KhQimBks5r5Il7gaJpZM4NFcW1>
.
|
|
Here is the updated linker script, which should run at 48 MHz. I haven't
tested it, so we can do it at the same time.
Thanks!
Larry
On Fri, May 12, 2017 at 9:44 AM, Brian Schmalz <notifications@github.com>
wrote:
… Yeah, there's some history there. I was developing the Fubarino Mini with
40Mhz parts, because that's all that was available at the time. Right
before we went into production, Microchip came out with the 50Mhz rated
parts. We decided to go with the 50Mz versions for production, and run them
at 48Mhz (so that USB would work).
So the first bootloader (the one without a speed in its name) is set to run
on a 40Mhz part. We did make some limited numbers of 40Mhz Fubarino Minis
(by hand), so I kept that bootloader around for folks that only have 40Mhz
parts.
The 48Mhz version should be used for both types of Fubarino Mini's that are
in chipKIT core.
On Fri, May 12, 2017 at 11:31 AM, Grzegorz Hołdys <
***@***.***>
wrote:
> There are two versions of Fubarino Mini: fubarino_mini_dev that uses
> Fubarino-Mini_USB_48MHz.hex and fubarino_mini that is mapped to
> Fubarino-Mini.hex. If both versions should use the 48MHz bootloader then
> what is the point of the other .hex file?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#15#
issuecomment-301124428>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AAbeCD1rlbOVWDjLTjOXetoNP8KhQimBks5r5Il7gaJpZM4NFcW1>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#15 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALyFRWvNvi6XTBrYbhPheFbLS7vQ3Mb3ks5r5IxigaJpZM4NFcW1>
.
--
"It is not necessary to change. Survival is not mandatory." - W. Edwards
Deming
|
|
Larry, there isn't an attachment on your github message. Do you want to send it to me privately? |
|
@EmbeddedMan, I've just uploaded version 1.0.4 with the new linker script for Fubarino Mini. Please verify if it works well. |
|
I have confirmed that this bug is fixed in v1.0.4 |
I believe that the importer is choosing the "Fubarino-Mini_USB.hex" bootloader hex when it needs to program a Fubarino Mini's bootloader. However, the proper one is "Fubarino-Mini_USB_48MHz.hex".
The only real difference is that the Fubarino-Mini_USB.hex runs the core clock at 40MHz, whereas the Fubarino-Mini_USB_48MHz.hex runs it at 48MHz. I'm pretty sure that Fubarino-Mini_USB_48MHz.hex is what comes on the board from the factory.
This was likely a screw up on my part when we were deciding what hex files go with what boards.
The text was updated successfully, but these errors were encountered: