Importer doesn't use correct bootloader image for Fubarino Mini

[EmbeddedMan]

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.

[EmbeddedMan]

Note this is with importer v1.0.0

[EmbeddedMan]

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).

[gholdys]

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".

[EmbeddedMan]

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 notifications@github.com 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 https://github.com/chipKIT32/chipKIT-importer/issues/15#issuecomment-299249291, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCJfTLzZkXL53NptQmzJnVZkxrvNbks5r2gZ8gaJpZM4NFcW1 .

[gholdys]

Just committed version 1.0.1. Please verify if this issue has been successfully resolved.

[EmbeddedMan]

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_FUBARINOMINI -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_FORSERIAL -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_FUBARINOMINI -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_FORSERIAL -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

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 notifications@github.com 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 https://github.com/chipKIT32/chipKIT-importer/issues/15#issuecomment-299268568, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCCULSQkSmuOqauPIETl6wJknPVvIks5r2hdggaJpZM4NFcW1 .

[gholdys]

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...

[EmbeddedMan]

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 notifications@github.com 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 https://github.com/chipKIT32/chipKIT-importer/issues/15#issuecomment-299467010, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCN3fHeeh_OpkEr-5suGSmkSSCNYCks5r2yaEgaJpZM4NFcW1 .

[gholdys]

I confirmed that the problem is with relative paths to library and source files. When the paths are absolute, the build works fine.

[gholdys]

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.

[gholdys]

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.

[EmbeddedMan]

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.

[gholdys]

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?

[EmbeddedMan]

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 notifications@github.com 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 https://github.com/chipKIT32/chipKIT-importer/issues/15#issuecomment-301124428, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbeCD1rlbOVWDjLTjOXetoNP8KhQimBks5r5Il7gaJpZM4NFcW1 .

[lstandage]

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 < notifications@github.com> 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 https://github.com/chipKIT32/chipKIT-importer/issues/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 https://github.com/chipKIT32/chipKIT-importer/issues/15#issuecomment-301127268, or mute the thread https://github.com/notifications/unsubscribe-auth/ALyFRWvNvi6XTBrYbhPheFbLS7vQ3Mb3ks5r5IxigaJpZM4NFcW1 .

-- "It is not necessary to change. Survival is not mandatory." - W. Edwards Deming

[EmbeddedMan]

Larry, there isn't an attachment on your github message. Do you want to send it to me privately?

[gholdys]

@EmbeddedMan, I've just uploaded version 1.0.4 with the new linker script for Fubarino Mini. Please verify if it works well.

[EmbeddedMan]

I have confirmed that this bug is fixed in v1.0.4