Messages

61

utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT

« on: May 20, 2022, 08:20:09 PM »

Hi

During the mounting of the card once of the first things done is to execute the
CMD55
CMD41
sequence.

Typically the first of these take some time to be performed by the SD card it returns its busy state until it has completed and the CMD41 can be continued with.

It is however not normal that the card never returns that it has completed the first command. This also means that this is not something that have been experienced and worked around before.

Is the card being use in SDHC or SPI mode?

Regards

Mark

62

NXP^TM M522XX, KINETIS and i.MX RT / Porting projects to the i.MX RT

« on: May 20, 2022, 08:07:16 PM »

Hi All

Due to the present processor shortage - especially Kinetis family parts - there is a lot of activity porting existing products to be able to run in i.MX RT parts, which tend to be more readily available.

During the transfer of code that has run correctly for years on the Kinetis (Cortex M0+, Cortex M4) there are some initial surprises when it hard faults on the Cortex M7 of the i.MX RT. The Cortex-M7 is very sensitive to alignment and I have found that the GCC compiler with high optimisation often generates code that access them with mis-aligned accesses and cause hard faults.

By reducing the optimisation of the compiler it often goes away and I also find that declaring variables that cause hard faults as volatile stops the compiler optimising and then corrects access alignment - from what I hear I expect you have also identified such.

I had a discussion with Eric Styger here (see discussion at the bottom) https://mcuoneclipse.com/2021/10/12/spilling-the-beans-volatile-qualifier/

where I believe that the use of volatile to solve such things (when they have been correctly understood) is valid. There are arguments about this being the wrong way but - as you can see - I think that it is valid in such cases and that is what I do use. You will find various such work-arounds in the code that were needed for the i.MX RT. For example, new routines
    21.12.2021 Add fnSafeGetBufLittleShort(), fnSafeGetBufLittleLong(), fnSafeGetBufBigShort(), fnSafeGetBufBigLong() {103}
    09.01.2022 Add fnSafePutBufLittleShort(), fnSafePutBufLittleLong(), fnSafePutBufBigShort(), fnSafePutBufBigLong() {104}
are used in some code and drivers to copy buffer content in a safe way.

Usually it is quite obvious that the hard faults are due to the compiler optimising accesses (trying to use 32 bit instead of 8 bit but accessing on unaligned boundaries) by looking at the disassembled code that caused the crash. Then adding the volatile keyword to the variables in question will show that it then doesn't optimise and the code works as expected.

It is a bit of a nuisance (IAR, for example, doesn't have this problem) but when you have experienced and solved it once or twice when moving existing code to the i.MX RT you will find that it is easy to recognise and solve so it is also not that serious.

Regards

Mark

63

NXP^TM M522XX, KINETIS and i.MX RT / Re: CANopen on i.MXRT?

« on: May 17, 2022, 01:46:42 AM »

Hi

It is correct that the driver layer used as reference was from a Coldfire reference but I don't know whether it actually worked since there were some things that didn't match the Coldfire's CAN controller. CO_driver.c is therefore mostly not used since it is HW dependent in its original from and has been made HW independent (but original content retained - commented out - as reference).

Then the interface was reworked to use the uTasker CAN driver interface instead and used in a product (probably about 4 years ago now) on a K64 of K66 .
The Kinetis has FlexCAN (as the Coldfires do/did) and the i.MX RTs also have the same FlexCAN.

If I enable CAN_INTERFACE and

Code: [Select]

SUPPORT_CANopen the project builds for i.MX RTs (although I had to disable two lines in CANopen.c due to a typedef being provided twice):

//typedef unsigned short    MAX_MALLOC;                                    // up to 64k heap chunks
//extern void *uMalloc(MAX_MALLOC);

It may be that that was never needed or became redundant and is only evident when MAX_MALLOC is typedef'ed differently in the application's types.h. My bet is that this is the case and so I will disable these since I don't see that they are needed since there is an include of "config.h" there to access it.

Theoretically this will already run on the i.MX RT since the FlexCAN driver is the only thing that is HW dependent and, since this driver is shared between Kinetis and i.MX RT and assuming it runs on the i.MX RT (which I haven't verified myself just yet - eg. a clock source could be incorrect for speed calculation or there be a register incompatibility somewhere) it will run on any Kinetis, i.MX RT or Coldfire with FlexCAN (although Coldfire is legacy and no longer worked with).

One restriction of the CANopen stack is that it only supports a single instance and so different CANopen instances can't be run on multiple CAN buses..

uCANopenApp.c is used as application interface to the CANopen stack - interfacing with the CANopen.c interface.
If a newer version of CANopenNode is used I expect uCANopenApp.c to remain the same and also CANopen.c to remain the same unless there are changes to the stack's API.
The rest of the newer CANopenNode stack would replace the previous version.

In each of the CANopenNode files I have added:

#include "config.h"

#if defined CAN_INTERFACE && defined SUPPORT_CANopen
...
#endif

which allows them to get their configuration defines from the application configuration rather than needing a configuration header which is not so easily maintained for multiple application use.

Therefore I essentially expect that the 2015 version of CANopenNode should be operational (worst case with a driver / i.MX RT specific correction).
A newer version would need to be integrated but I don't expect any real complications as long as the interface files continue to do their job of keeping the CANopenNode code itself independent to the application's / HW interface.

Regards

Mark

P.S: There is a possibility that I will shortly be using CANopenNode in an i.MX RT based product development and then I would also need to decide whether an upgrade makes sense as part of this work.

64

µTasker general / Re: Can't build simulator app

« on: May 03, 2022, 08:50:43 PM »

Hi

Those two headers are supplied by the compiler library which is presumably either missing can't be found.
It may be something with VS 2022 (I am still using VS 2019) or it may be something missing during its installation - potentially you haven't installed an option that is required since, if i remember correctly, VS 2019 installs the IDE but not all of the language packages and it may be that you need to tell it that you need its C/C++ package which will then deliver the missing libraries.

As a reference I find these two missing files in the folder
C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt

I believe VS 2022 is being used by some and I didn't hear of such issues and therefore I am tending to think that it will be an installation option problem - check out this Microsoft page and verify that the "Desktop development with C++" workload is included.

Good luck

Regards

Mark

65

NXP^TM M522XX, KINETIS and i.MX RT / Re: BOOT_MAIL_BOX location

« on: March 22, 2022, 09:32:19 PM »

Hi Caleb

In fact the boot loader and application can have different memory bank layouts as long as the persistent memory (mail box) is always located at the top of the DTC or the FlexRAM layout is left unchanged.
For this to work (with reconfigured banks) the only requirement is the ordering of the banks - see section RAM and Cache in https://www.utasker.com/docs/iMX/i.MX_RT_1060_uTasker.pdf (although I think that the OCRAM addresses may be incorrect in the image since OCR in the 1062 starts at 0x20280000)

From the diagrams there it is seen that as long as the banks are used in the order IIIIDDD (however many banks are allocated to I) the persistent memory is located at the top of the last D bank.
The absolute address changes of course but the relative address (referenced to the top of D bank memory) remains the same.

fnGetPersistentMemory() returns the memory content relative to the top of memory (it simply assumes that the present stack is there, which would normally be the case).

The boot loader uses the chip's default memory layout and the application can also use it too, as long as its stack pointer is set to the same.

Beware that as banks are reconfigured their absolute addresses change, meaning that if a different strategy were used the absolute address of the boot loader's banks would move around as the application uses different layout and this is the reason for choosing this strategy so that it is (irrespective of how the application configures its bank usage - which can change as a project develops [but respecting the order the banks so that D is always the last]) in fact already solved.

Regards

Mark

66

NXP^TM M522XX, KINETIS and i.MX RT / Re: UDP and TCP server

« on: March 16, 2022, 05:50:46 PM »

Neil

For Telnet there is:
https://www.utasker.com/docs/uTasker/uTaskerTELNET.PDF
(although not a complete description)

For TCP there is:

https://www.utasker.com/forum/index.php?topic=25.0

(which also has examples from Telnet configuration and use)

UDP is so simple it is best to experiment with a simple listener.

Regards

Mark

67

NXP^TM M522XX, KINETIS and i.MX RT / Re: UDP and TCP server

« on: March 16, 2022, 04:12:38 PM »

Hi Neil

Use the HTTP server as reference for a TCP server using simple socket mode.
Use the TELNET server as reference for a TCP server using buffer socket mode.

The only difference between a UDP client and a UDP server is that the USB server is set to listening mode rather than actively connecting to a remote UDP server. The UDP callbacks are otherwise identical. As a server you will generally be listening for data which can arrive at any time and when it does you will receive an appropriate callback event to handle the data - the server will generally make a not of the client's details (eg. its IP address and source port) and can subsequently send data to it in the same way as a client does.

Regards

Mark

68

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« 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

69

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« 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

70

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« 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

71

USB / Re: Transition from HS to FS USB

« 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

72

USB / Re: Transition from HS to FS USB

« on: February 28, 2022, 04:24:24 PM »

Alex

I understand you can have a hard fault in the following sequence:

1. (Called from USB OTG interrupt and interrupts globally disabled for fnUSB_handle_frame() handling)
                uDisable_Interrupt();                                    // ensure interrupts remain blocked when handling the next possible transmission
                    fnUSB_handle_frame(USB_TX_ACKED, 0, iEndpoint_ref, &usb_hardware); // handle tx ack event
                uEnable_Interrupt();                                     // allow higher priority interrupts again

2.  (when extra data to send is in a linear block)
                FNSEND_USB_DATA((tx_queue->ptrStart + tx_queue->usSent), usDataLength, iEndpoint, ptrUSB_HW); // transmit next buffer
                fnPushLastLength(ptrUsbQueue, usDataLength);             // save last length for use later
                tx_queue->usSent += usDataLength;                        // total frame length in progress

3. Where
        #define FNSEND_USB_DATA(pData, Len, iEndpoint, ptrUSB_HW) *ptrUSB_HW->ptrTxDatBuffer = (unsigned char *)pData; \
                *ptrUSB_HW->ptr_ulUSB_BDControl = (unsigned long)(SET_FRAME_LENGTH(Len) | (OWN | ptrUSB_HW->ptrEndpoint->ulNextTxData0)); \
                _SIM_USB(0, USB_SIM_TX, iEndpoint, ptrUSB_HW); \
                ptrUSB_HW->ptrEndpoint->ulNextTxData0 ^= DATA_1; \
                ptrUSB_HW->ptrEndpoint->ulEndpointSize ^= ALTERNATE_TX_BUFFER

and
the struct in question starts with
typedef struct stUSB_HW
{
    unsigned long  ulRxControl;
    volatile unsigned long *ptr_ulUSB_BDControl;                         // pointer to the presently valid tx buffer descriptor control entry
    USB_END_POINT *ptrEndpoint;
....

and
typedef struct stUSB_END_POINT
{
    unsigned long ulNextRxData0;
    unsigned long ulNextTxData0;
    unsigned long ulEndpointSize;                                        // contains size of endpoint plus some control flags
} USB_END_POINT;


4. From the screen shot it looks like this line can do it:

*ptrUSB_HW->ptr_ulUSB_BDControl = (unsigned long)(SET_FRAME_LENGTH(Len) | (OWN | ptrUSB_HW->ptrEndpoint->ulNextTxData0));

and specifically the
ptrUSB_HW->ptrEndpoint->ulNextTxData0
can fail.

5. The assembler  to this is
ldr r2, [r7, #0]
ldr r2, [r2, #8]
ldr r2, [r2, #4]

ptrUSB_HW is in the register R7 (0x2002ff48), which points to a location at 0x2000ff48 according to the memory window.

r2 is however showing 0x400000, which is the previous content which is typically SET_FRAME_LENGTH(Len) [0x40 << 16], meaning that either this instruction has either not yet been executed or has been overwritten.

If the second assembly instruction is failing (with R2 at 0x400000) it would indeed be a read fr0m 0x400008, which is an invalid address, whereby the instruction's aim is to load the pointer ptrEndpoint so that the following instruction can load the value of ulNextTxData0.

The struct looks to be intact and the location of ptrEndpoint would be OK.

Can you check how uDisable_Interrupt() is set up in your system? I know that you are using FreeRTOs with the USB stack and USB driver and, since it doesn't look possible for r2 to not have the correct value after the first assembler instruction has been executed, I would carefully ensure that no task switching could be taking place (that is, that it is really correctly protected) and the register instance somehow being changed in the process.

Regards

Mark

73

NXP^TM M522XX, KINETIS and i.MX RT / Re: combining applications & jumping between them (uTasker+ teensy 3.2).

« on: February 27, 2022, 11:10:34 PM »

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

74

USB / Re: Transition from HS to FS USB

« on: February 24, 2022, 12:02:37 AM »

Hi Alex
Could you post a reference where is is working since at the moment i don't understand what the log is showing and what the error actually is.
There is something about an unsuccessful stall PID in an IN bulk or interrupt transfer, but I don't see any details about what endpoints are being used.
Also, is it possible to see the enumeration too so that the device details are known?
Regards
Mark

75

µTasker general / Making the "Solution Configurations" drop-down wider in Visual Studio

« on: February 14, 2022, 04:09:44 AM »

Hi All

When using VS and its simulation of uTasker projects the "Solution Configuration" drop down (where it shows the target being used) tend to be rather narrow by default and so the target selected is not really visible. It can however be configured to be wider so that it becomes much more useful, as long as it can be worked out how to actually do it.

Here is the method:

1. Hover your mouse over the "Solution Configuration" and press right mouse to see the context menu.



2. Select "Customize..." - right at the bottom.

3. Now select the "Standard" Toolbar in the Commands tab and select "Solution Configurations" before commanding "Modify Selection", which gives the possibility to change its width setting:



Regards

Mark