Recent Posts

Pages: 1 ... 8 9 [10]
91
NXPTM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).
« Last post by mark on March 15, 2022, 12:40:10 AM »
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
92
NXPTM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).
« Last post by Alex1982 on March 14, 2022, 03:51:14 PM »
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
93
NXPTM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).
« Last post by mark on March 13, 2022, 08:10:07 PM »
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


94
NXPTM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).
« Last post by Alex1982 on March 12, 2022, 08:03:17 AM »
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
95
USB / Re: Transition from HS to FS USB
« Last post by AlexS on March 11, 2022, 07:46:15 PM »
In order to have some sort of conclusion on this. After reducing the Kinetis flash clock to 20MHz (from 24Mhz, confirmed using an oscilloscope), the hard fault disappeared. After further investigation into another issue (noisy ADC readings) we believe the problem is actually the design of the chip's power supply lines. Instead of a 3V3 plane with decoupling capacitors close to the pins themselves, our design has a single trace running from all the 5 supply pins to the outside of the chip and then the decoupling capacitors are all placed in parallel there.

We're currently doing another design iteration to confirm that was indeed the problem. Will update this post when that happens. Thanks for your help!
96
NXPTM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).
« Last post by mark on March 01, 2022, 07:37:33 PM »
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
97
NXPTM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).
« Last post by Alex1982 on March 01, 2022, 04:10:51 PM »
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
98
USB / Re: Transition from HS to FS USB
« Last post by mark on March 01, 2022, 03:24:02 PM »
Hi Alex

I did once run the flash clock of a Kinetis part slightly out of specification (by mistake) and found that it would crash very quickly.

24MHz is within spec. so reducing to 20MHz and finding a difference could mean that the chips are not fully qualified. There is another product that I am involved with that needed to move from a K66 to a K22 due to chip supply problems. In that case it was abandoned since a standard Cortex-M4 instruction caused an unknown instruction hard fault when used by compiled code. Instead a redesign with an i.MX RT part has been used.

Therefore, although I didn't physically test the K22s myself, it is worrying that possible Kinetis parts that are now in circulation may not be up to scratch.

In other products recycled chips are being used (taken from scrapped equipment) - there are some good stocks from companies specialised in recycling which, although already a number of years in service, careful testing has shown that they have proven reliable.

My general advice for all in a difficult situation with Kinetis part supply (where the end is still not in sight) is to seriously consider i.MX RT alternatives since these, although requiring a HW change, is an intelligent long-term investment that has multiple advantages. uTasker users can simply move between Kinetis and i.MX RT since existing products can run on these with very little configuration (in the best case by changing the _KINETIS define to _iMX and adjusting the port muxes to suit).

Regards

Mark



99
USB / Re: Transition from HS to FS USB
« Last post by AlexS on March 01, 2022, 01:33:04 PM »
Quick update: it seems that it wasn't the core clock influencing the hard fault occurrence, but actually the flash clock.

Anecdotally, after a few tests:
1. Core clock 96MHz, flash clock 24MHz -> getting faults as often as before
2. Core clock 120MHz, flash clock at 20MHz -> not getting the faults
100
USB / Re: Transition from HS to FS USB
« Last post by AlexS on March 01, 2022, 12:23:44 PM »
Hi Mark,

Thanks for your reply! Have managed to make some progress, but said progress just muddied the waters in terms of what's causing this.

I'll outline below what I have done to debug this and the results:
1. Initially I disabled all instruction and data caching and prefetching. This move has totally eliminated the hard fault occurring in the fnUSB_handle_frame() function and only left me with hard faults that are shown to originate in the prvPortStartFirstTask() function (I've added a picture)
2. Then, when I reduced the clock multiplier from 30 to 24 (essentially lowering the core frequency from 120MHz to 96), all problems essentially disappeared. Which is very odd considering the fact that the USB clock is derived from the internal 48Mhz reference, not from external sources.
3. I then enabled back instruction and data caching and prefetching, got back some of the performance I lost, but the system stayed stable.

As you can see, it's a very odd sequence of events. I can't see how reducing the core speed would get rid of all the issues, unless the system was overclocked to start with.

LE: uDisableInterrupt() (have removed what the precompiler leaves out)

extern void uDisable_Interrupt(void)
{
    __disable_interrupt();                                               // disable interrupts to core
    iInterruptLevel++;                                                   // monitor the level of disable nesting
}
Pages: 1 ... 8 9 [10]