combining applications & jumping between them (uTasker+ teensy 3.2).

[Alex1982]

Hello,

I wish to use a combination of 3 applications on MK20DX256 (teensy 3.2)

The main application is compiled in teensy/arduino and the second is uTasker1.4 and serves as USB-MSD allowing user to access an SD card within the device over USB.

I'm following the steps explained here.
https://github.com/pixelmatix/JumpToUsbMsdAppWithOffset/

To summarise:
Main application is located at 0x00000
USB-MSD is located at 0x38080
We jump from main to USB-MSD @ 0x38080

Everything works when flashing the 2 combined hexes to a blank MCU.

However I wish to use the 2 above applications on top of a third uTasker bootloader application:

0x00000 uTasker bootloader
0x05080 Main application
0x38080 USB-MSD

This is where I have an issue:
the uTasker bootloader won't accept the 2 combined applications (arduino application with 0x05080 start address and USB-MSD with start address 0x38080).
The bootloader won't reboot after transferring the combined hex

Must I change the USB-MSD start address (move forward by 05080?) to compensate for the bootloader offset?
I'm unsure if the address is absolute or relative to the starting address of the main application...

Many thanks in advance, sorry in advance if this is off topic and happy weekend!
Alex

[mark]

Hi Alex

I assume that your serial loader build is less that 0x5000 in size so that you change the application's start address form 0x8080 to 0x5080. In this case it is Ok since it avoids leaving unnecessary unused space.
However you need to set up the serial loader to expect the application to be there by setting UTASKER_APP_START accordingly (0x5000 in this case instead of the standard 0x8000).
One check that the serial loader does when accepting a new file is to check that its initial program counter value is within Flash and it would probably ignore an application linked to a lower address than expected.

Regards
Mark

[Alex1982]

Hello Mark
Many thanks for your quick response, 0x5080 is definitely fine (you kindly helped set it up for me at this address) - no problem uploading single applications.
The issue only occurs when trying to load combined applications (2 hex files combined with srec_cat).

Would it be possible to combine a teensy .hex with a utasker .bin (or .hex) using your uTaskerCombine.exe tool?
Thanks!
Kind regards
Alex

[mark]

Alex

Are you sure the loader is set up to accept srec files? Normally it accepts binary.
You can use the uTaskerCombine.exe tool to combine two binary files - I don't expect there to be a problem with it accepting that.

Regards

Mark

[Alex1982]

Hello Mark

Thanks for your reply. I believe the format is correct (intel hex) as I'm specifying the -Intel in the command line:

srec_cat MAIN.hex -Intel SD.hex -Intel  -Output COMBINED.hex -Intel

The resulting COMBINED.hex works fine with the teensy loader on a blank MCU with MAIN.hex compiled with start address 0x00000000.
And it will happily jump to SD.hex and mount the SD card on a computer.

uTasker loader will accept and load MAIN.hex alone (compiled with start address 0x00005080)
but not when I attempt to combine with SD.hex (compiled start address 0x00038080).

Can you please advise what command I should for your uTaskerCombine.exe to combine:

 MAIN.hex(compiled with start address 0x00005080)
SD.hex (compiled start address 0x00038080).
The resulting HEX should have a start address of 0x00005080.

Thanks and sorry for ignorance!
Kind regards
Alex

[mark]

Hi

The utilities are described in https://www.utasker.com/forum/index.php?topic=1445.0

In your case I would avoid the use of hex files for uploading since binary files are easier. You can convert your two hex files to binary versions using GCC objcpy and then this command can be used

uTaskerCombine main.bin SD.bin 0x33000 fileOut.bin

This will generate a binary output which starts with the content of main.bin and the content of SD.bin at an offset of 0x33000. Any gap between the end of main.bin and the start of SD.bin is filled with 0xff.
The start of this will be located at 0x5080 by the serial loader copy so the start of SD.bin will end up at 0x38080.

Beware that the file is quite large so make sure that the serial loader will accept it and not cut it short (if the max application size is set too small) [this is also relevant for the hex method too].

Regards

Mark

[Alex1982]

Hello Mark

Thanks a million for your help, using bin files worked!

I can now load and boot teensy app from utasker bootloader, and jump to utasker USB-SD card at runtime!

The only question mark remaining is that it takes about 40-60seconds for the SD card to mount on OSX systems (tried several computers). The disk utility can see the device (grayed out) after about 12seconds, but it takes 30-40 seconds more to appear in the finder.
However on windows machines (win7 and win10) the SD mounts within 4-6 seconds

Does anything come to mind that could cause the delay?

Even at the slow mount speed it's already a victory, I can advise OSX users to be patient...

Thanks again for your great support!
Kind regards
Alex

[mark]

Hi Alex

Thanks for the feedback - I am pleased to hear that the binary based technique proved to result in a solution.

As for the OSX slowness - I don't know anything specific except that it may be that it is loading the complete content of the disk (FAT and data?) to the computer so that it has a cache for faster (subsequent) operations. If you have a large card it may take some time as it is not a fast USB connection (a smaller card would, if this is the case, load faster).
You may find settings that control the amount of caching that the computer does (?)

Windows, which I know better, reads in some FAT tables to cache but may do a lot less and so show the disk faster.

However I don't know for sure and a USB analyser that understands MSD would be the best method to see what is happening and whether the delay is due to USB activity needing to first terminate, or not.

Regards

Mark

[Alex1982]

Hi Mark

You are correct, smaller SD cards mount faster. 

Thanks!