uTasker V1.4 SerialLoader - FRDM-KL26Z - MSD "Device not recognized"

[mark2]

Hi Mark,

Please can you give me some pointers building SerialLoader for FRDM-KL26Z board? The code builds and downloads to the board, and I see the uTasker Serial Loader V1.5 interface on a the Segger VCOM port. Start address is 0x00008080 and bc/dc/ld are working. Strictly, the loading hangs when I try to load uTaskerV1.4.8_BM_FRDM-KL26Z_8080.srec (I converted uTaskerV1.4.8_BM_FRDM-KL26Z_8080.bin to srec using tool srec_cat BM_FRDM-KL26Z_8080.bin -binary -offset 0x8080 -o test.srec) but when I get the MSD working I'll try with the binary file.

But I see a "Device not recognized" from Windows 10 when I attach to USB port on my PC. The board heartbeat LED (green) flashes during the enumeration, and then sticks on or off. Normally this is a clocking issue, but if I run the code in debugger, the code is in irq_default(), caused by __aeabi_uidivmod() called from fnUSB_handle_frame(). 

#if defined USB_DEVICE_SUPPORT // {29}
if ((tx_queue->usCompleteMessage % tx_queue->usMax_frame_length) == 0) { // if the transmitted data length was divisible by the frame length
if ((tx_queue->usLimitLength != tx_queue->usCompleteMessage) || (fnControlEndpoint(iEndpoint, iChannel, (USB_ENDPOINT_TERMINATES)) != 0)) { // {26}
FNSEND_ZERO_DATA(ptrUSB_HW, iEndpoint); // send a zero frame to terminate status stage
}

So I don't think this is a clocking issue. Same behaviour with 2nd Windows 10 machine, same behaviour with W7 and same behaviour with Mac OX 12.4 Monterey.

The 'background'.

The code is compiled in MCUXpresso v11.5.1. Source provenance is from git repo uTaskerV1.4. Since I am using MCUX, I've coped the 'template' project files .project and .cproject into the top directory. 

I'm using a 'stock' FRDM-KL26Z (but with Segger JLink installed on the CMSIS-DAP debugger). The board is working OK with *.bin files downloaded from https://www.utasker.com/kinetis/FRDM-KL26Z.html

Inside the project, I've set the architecture to Cortex M0+, updated the linker file to KL_128_16.ld and selected FRDM_KL26Z in the config.h file. This all appears to be configured OK - clock settings match the board for example - and there is no SD card on this board (so #define SDCARD_SUPPORT is not defined, etc). Searching the project for FRDM_KL26Z doesn't return many locations, and I've checked them all. I wasn't sure about USB_CLOCK_GENERATED_INTERNALLY in app_hw_kinetis.h but I've tried it commented and not commented, without success.

One common problem building bootloaders is they get too big and overflow the space reserved for them. This build has BM load address starting at 0x00008080 and the image size for the bootloader is less than this. Last line address in uTaskerSerialLoader.srec in \Applications\uTaskerSerialboot\MCUX\uTaskerSerialLoader_FLASH\uTaskerSerialLoader.srec is 0x5094 so I don't believe that the bootloader is corrupted. But your image from the above URL is 0x401a / 16410 bytes. I don't know why mine is bigger (I'm using -Os). 

I'm going to test an earlier version of MCUXpresso IDE later today and will report back with progress.

[mark2]

Thanks for the tip, Mark. @mjbcswitzerland 

I've downloaded & installed MCUXv11-4-0 & imported uTasker project into a new, clean workspace with 'template' .project and .cproject files.

I've done all the expected things - clean project, set FRDM-KL26Z in config.h & checked that the expect clock settings etc are as expected. Then I've set the cortex M0+ in the Compiler settings, set KL_128_16.ld in the linker settings (and also tried setting Cortex M0+ in the Assembler and Linker settings).

This is the outcome:

uTasker_v1.4_FLASH

1) blinky - compiles, downloads to board (both via debugger and drag&Drop with Segger CMSIS-DAP), heartbeat LED flashes.

2) hello world - compiles, downloads to board (both via debugger and drag&Drop with Segger CMSIS-DAP), heartbeat LED OFF, no UART activity. Project is hung in debugger, __init_gnu_data(). I didn't record in which of the while(ulInitDataLength-- !=0).

uTaskerV1.4<uTaskerSerialLoader_FLASH>

Compiles, downloads to board (both via debugger and drag&Drop with Segger CMSIS-DAP), no heartbeat LED. I've not investigated with the debugger where it has hung. But I have not got as far as I did with MCUXv11.5.1, where at least I got some VCOM activity.

One thing that I'd like to try is re-downloading the Git repo. There are a lot of places where lines of code are commented inside of a #if defined, and I cannot guarantee that the code is as you intended. I did try to redownload the repo with tortoise but suspect that the credentials that you issued were "one time" or have timed out, since I can no longer connect to the repository. Can you provide access again?

[mjbcswitzerland]

Hi Mark

Sorry, that was a red herring. The Kinetis project is not affected by the latest MCUXpresso (GNU) compiler version; it is only the i.MX RT target that fails due the the reason stated (Cortex M7).

I tested the serial loader USB-MSD build and found that

#define USB_MSD_DEVICE_SECURE_LOADER

is enabled by default, which enables AES256 encrypted operation.
The crypto libraries requires about 8k of SRAM and, seeing that the KL26 has 16k that gets tight and I saw that a uMalloc() call was failing when peripheral buffer memory was requested.

Specifically I tried encrypted USB-MSD and SREC loading support on serial and found that a total of 12k data was occupied by data and bss (with the crypto library contributing 8k of this). The heap size (see OUR_HEAP_SIZE define in config.h for the target in question) was set to 8k but has to be limited to about 4k so that it fits in the physical space left (which is done automatically).
USB was then taking a couple of kBytes for its use and when the UART needed to be opened it didn't have enough and so failed. Subsequent use of a buffer causes a zero pointer to be used and therefore somewhere there was a fault. There was not that much missing so specifying smaller UART buffers (or USB buffers) would probable make it possible but if you disable the encrypted support it will halve the RAM requirement and so have plenty of head room and not fail.

The loaders tend to be built with _MINIMUM_IRQ_INITIALISATION and so the fault interrupt is not so specific (to save a bit of code and RAM) but without this the reason for such a fault would be more exact.

Good luck

Regards

Mark

[mark2]

Just seen your latest update.

Let me try in the morning and report back.

[mark2]

I have this:

#if defined USB_MSD_DEVICE_LOADER
#if defined _iMX
#define USB_MSD_DEVICE_SECURE_LOADER // i.MX usually always uses encrypted mode
#else
//#define USB_MSD_DEVICE_SECURE_LOADER
#endif
#define USB_DEVICE_SUPPORT // requires USB device driver support
#define USB_MSD_TIMEOUT // if there is no enumeration within a short time the application will be started (or the host mode will be switched to if used together with USB_MSD_HOST_LOADER)
//#define FAT_EMULATION // use fat emulation R60287
#if defined FAT_EMULATION
#define EMULATED_FAT_LUNS 2

[mjbcswitzerland]

Mark

I have attached the binary that I just built. I tested with a make file build with the GCC version in MCUXpressoIDE_11.5.0_7232 and also with IAR9 with the same result.

uTaskerV2.0_BM_KL26 is a reference application (also with USB) that I also just built, which can be loaded to it with drag-and-drop.

serial_loader.zip contains the config.h I set up for the board/serial loader options and a couple of code optimisations made since last checking in (which shouldn't have any effect) but if you use these you should have an identical build.

Regards

Mark

[mark2]

@mjbcswitzerland many thanks for the quick response.

The binaries work OK, simply drag & dropped the uTaskerSerialBoot onto the FRDM-KL26J drive and it all started as expected. MSD worked and UPLOAD_DISK appears. Perfect.

I started to diff the 3 files from serial_loader.zip with my project, but of course there are many, many changes (practically none relate to FRDM-KL26Z). So I just accepted all the changes. 

Now with my project set for FRDM-KL26Z, KL_128_16.ld and Cortex-M0+, it will not compile.

undefined reference to 'fnSafePutBuf[Big][Little][Long][Short] in usb_device_loader.c. I searched the project for the definitions for these functions, without success. Am I missing a library? All the USB functions seem to be in usb_application.c but I don't have fnSafe...

To be fair, I am using MCUXv11.5.1 whereas you are using 11.5.0, but I don't think that explains the differences in build.

[mjbcswitzerland]

Mark

Please switch to the V2.0.0 branch, which includes fnSafePutBuffer() etc. then you will have the exact same libraries as I used. These functions were introduced for Cortex-M7 (i.MX RT) since higher GCC optimisation otherwise often results in misaligned errors when extracting and inserting variables into byte streams.

Regards

Mark

P.S. If you don't solve it please send me the FRDM-KL26Z binary that you generate so that I can see what happens with it.

[mark2]

Hi Mark,

You provided me access to the GIT repo with username and password on 1 June. I've previously been able to download the root branch, but in the last few days I don't get past security:

Please can you resend/reset the password?

[mjbcswitzerland]

Hi Mark

Free commercial accounts time out after 5 days according to the licensing agreement.

However you don't need access to switch between branches. When you clone the repository you have all branches contained in the local copy and you can switch between branches using the GIT switch/checkout command. I think it will ask you to stash any changes made so it can do this but essentially you can freely switch around between branches and specific commits without losing any work or having to specifically back-up data (the great feature of GIT).

I have also reset your account so that you have another 5 days access in case of any complications.

Regards

Mark

[mark2]

Update.

I reverted to your older method (see fnGetContentAddress() for example) for reading/writing the buffers. Obviously the code then builds, but - provided I optimise -Os - then it runs on the board. bc\dc are working.

I still see the application hang when I connect to USB, though.

I'll wait for your advice.

[mark2]

Thankyou for the ongoing help, Mark.

I stashed changes, and switched to v2.0.0 branch.

Imported uTasker v1.4 into a clean, new workspace in both MCUXv10.5.0 and MCUXv10.5.1. 

Set uTasker_v1.4_FLASH to be active build configuration.

Updated C/C++ compiler architecture, linker file, config.h for FRDM-KL26Z, blinky, APPLICATION_WITHOUT_OS. Does not compile: fatal error: stream_buffer.c #includes "FreeRTOS.h" which is not found. Recompiling with //APPLICATION_WITHOUT_OS fails to build in the same way.

Set uTaskerSerialLoader_FLASH to be active build configuration. Update the architecture & linker file.

Copy your 3 files config.h, serial_loader.c, usb_device_loader.c into the project, overwriting the existing files. Compiles, and runs on the FRDM-KL26Z. Heartbeat green LED flashes, prompts come up on the VCOM, bc/dc work as expected. On attaching MSD to host W10 computer, the application repeatedly restarts, and prints the  uTasker Serial Loader V1.5 menu into VCOM.

The binary that I created is attached. This one is from MCUXv11.5.0 but its the same result as v11.5.1. The entry point is very different from your binary, but once the code starts up, it is very much the same code.

Preprocessor directives are _KINETIS, _KDS, _GNU, _NEWLIB_  

[mjbcswitzerland]

Mark

In MCUXpresso select the file FreeRTOS -> stream_buffer.c

Then edit its properties and include these paths to its MCU C compiler included paths

"${ProjDirPath}/FreeRTOS/Source/include"
"${ProjDirPath}/FreeRTOS/Source/portable/GCC/ARM_CM4F"

stream_buffer.c is new in the FreeRTOSv10 and this was updated recently but MCUXpresso needs to be informed of its include paths.

You don't need FreeRTOS configuration so you could also exclude the FreeRTOS folder from the project too.

If you get missing headers widgets.h execute the widgets.bat file before building. This is because MCUXpresso generates its own make files based on what it find in the folders and sometimes decides it wants to access it, even graphics are not being used.

Regards

Mark

[mark2]

Binary

[mjbcswitzerland · Accepted solution]

Hi Mark

I loaded your binary and looked where it hangs when you connect the USB.
The assembly instruction is
DIVU R0, R0, R1
which looks to be consistent with the C-code % operation that you showed.

As you see from the following Cortex-M instruction chart this instruction doesn't exist in the Cortex-M0+

and the fault that is called is in fact due to an invalid instruction being executed.

Therefore you have MCUXpresso set up incorrectly as it must believe that you want to build a Cortex.M3 (or above) based project.
Another possible explanations that you have in fact set it up to Cortex-M0+ but its floating point setting is wrong (this is a bit of a problem with MCUXpresso since changing from an FPU based processor (with FPU in HW enabled) to one without "can" leave the FPU setting still on although it is not displayed and can't be edited).
To solve this do the following:
- select a processor with FPU
- Configure its FPU setting to "use SW library" rather than HW.
- Now set back the Cortex-M0+target (this ensures the FPU setting doesn't stick as HW implemented, which otherwise spells almost certain death to any code generated)


Another tip.
Don't build with MCUXpresso but instead just double click on the bat file "GNU_Kinets/Build_Kinetis.bat"
(after setting your GCC tool path in it if not already included as a system path)
(and after checking that make_uTaskerV1.4_GNU_Kinetis is comments to use the lines

C_FLAGS = -mcpu=cortex-m0plus -mthumb -mlittle-endian -mthumb -Wall -Wstrict-prototypes -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -Wundef

and

LINKER_SCRIPT = KL_128_16
)

This is almost fool proof so if it runs and the MCUXpresso build doesn't you can be quite sure it is a config there (they build with the same GCC tool chain).

Generally with MCUXpresso it is a good idea to first install an SDK for the processor that you want to use and then select it as target (rather than using generic processor targets). This will ensure that it is set up correctly and also the debugger support is there - it can all be configured manually but there are various pitfalls (such as the FPU settings sticking as one example) which can cause a lot of lost time until you get to grips with its idiosyncrasies and secret trap-doors for the unwary.

I'm sure it will start working for you shortly!

Regards

Mark

[mark2]

What an ordeal, and of course you were 100% correct. All working now.

In my installation of MCUXpresso (11.5.1 and 11.5.0) it seems that setting the architecture to Cortex M0+ (in Compiler, Assembler and Linker settings) is not sufficient to force a build for CM0+. I needed to revert to Cortex M4, then set FP to "None", then set Cortex M0+. Lastly there were 600+ errors originating from the mmcau assembler *.s, which I excluded from the build. 

Now, 'my' code built for FRDM-KL26Z with the SDK v2.2.0 and the SDK linker file modified for 0x8080 is running just fine (once I remembered to service the watchdog ) with loading via UART and MSD.

[mjbcswitzerland]

Hi Mark

Warning: If using MCUXpresso please note that V11.5 doesn't work with the project due to a GCC linker problem with the GCC version used. Please use MCUXpresso V11.4 until this has been worked around - this can be installed in parallel to other versions

I am sorry that this warning was not in your welcome pack but it is very rare that Kinetis is used nowadays since they are almost impossible to purchase and the text hadn't been added since the V11.5 became available.

V11.4 is Ok but V11.5 doesn't respect the SIZEOF(.data) used in the linker scripts which all compute to 0 rather than the actual size of the memory - so the linker puts different parts of memory on top of other parts of memory and so it can't run (in fact I didn't think it could even link so I am surprised you could generate a binary to try with....!

Regards

Mark

[bobpaddock]

I wonder how such a serious bug like that slipped through the GCC (binutils) testing cracks?

Do you know if there is an official bug number for it?