Messages

46

µTasker general / Re: How to view debug messages on the uTasker Simulator

« on: November 30, 2022, 01:05:26 AM »

Hi

If you would like the simulated processor to connect to a UART on the PC (the UART needs to be available as either RS232 port or VCOM) you can set the define for the corresponding processor UART in app_hw_xxx.h (where xxx is the processor reference).

#define SERIAL_PORT_0    10                                          // if we open UART channel 0 we simulate using comx on the PC

This would connect the first UART (or LPUART) to COM 10 (so you would need an interface COM10 to be available).

The simulator doesn't "create" an interface, but instead "uses" one.

This technique allows the simulated processor to communicate with another system connected to the PC via a UART and supports multiple UART too.


The second technique is to install a virtual serial loop-back (like COM0COM - see https://www.utasker.com/forum/index.php?topic=2012.msg7618#msg7618) which creates two virtual COM ports on the PC that are connected. For example COM10 and COM11.

If this were configured the PC would have these two COM ports and the above configuration would communicate on COM10, which is looped-back to COM11. That means that a terminal emulator can be opened on COM11 that receives all data sent by the simulated processor on its first UART. All data sent by the terminal emulators is correspondingly received by the UART of the simulated processor so that it behaves as a terminal emulator connected to a device (as in the case of your terminal emulator connected to the serial interface of the FRDM-K64F board).

Regards

Mark

47

ST^TM STM32 and STR91XF / Re: STM32 uTaskerBoot Project

« on: November 30, 2022, 12:53:52 AM »

Hi

I have already added these to the OS project so there is no need to purchase a license and use the professional version unless you are developing a product that will benefit from additional functionality and support.

In the case where the professional version would be of benefit an application can be made at https://www.utasker.com/Licensing/License.html or it can simply be purchased on line https://www.utasker.com/Payment/Payment.html, after which you will receive an account.

Regards

Mark

48

ST^TM STM32 and STR91XF / Re: STM32 uTaskerBoot Project

« on: November 28, 2022, 02:04:16 AM »

Hi

The open source project supports the ADC and port interrupts but the reference application didn't include the STM32 interface (instead it was using a Coldfire one, which generated the errors).
I just checked in new versions of
ADC_Timers.h
and
Port_Interrupts.h
which includes the STM32 interface.


The open source version is freely and anonymously available (supporting Kinetis and STM32) but is several years behind the development state of the professional version and doesn't include things like security, or WiFi support, for example. It is also not supported - apart from some bug fixes and occasional updates.

The professional project version is a supported version with much extended functionality and continuous development of features. It is not intended for hobby use and is licensed in professional product developments:
Licensing is detailed at https://www.utasker.com/Licensing/License.html
Prices are detailed at https://www.utasker.com/Licensing/Prices.html
and licenses are purchased at https://www.utasker.com/Payment/Payment.html
which are either single product (3 months of personal support and access to the development repo.) or full (any number of products and 12 months support and access).

Regards

Mark

49

NXP^TM M522XX, KINETIS and i.MX RT / Re: setting up FlexRAM from loader for iMXRT1062

« on: July 25, 2022, 12:49:48 AM »

Hi

The i.MX RT1062 has 512k FlexRAM and 512k OCRAM2. The 512k OCRAM2 is not part of the FlexRAM and its size and location are fixed.
This means that
0f000f would be referring to only FlexRAM and giving
480k DTC, 0 ITC and 480k OCR, which is not possible as there is not so much FlexRAM.
therefore the question is what you are referring to with your 512k OCR size? If it is the fixed OCRAM2 it is not in the FlexRAM and the FlexRAM setup would be 100000 16 x DTC banks (at 32k each) for a total of 512k DTC, 0 ITC and 0 OTC (with 512k fixed OCRAM2).

The header is 760 bytes in total (required padding size) and the first two bytes are 0x2f8 (760) to indicate its size (in case it were to change at some point). The size entry is therefore a part of the overall padding and so I think that the document is accurate.

Regards

Mark

50

NXP^TM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?

« on: June 29, 2022, 12:50:38 AM »

Neil

If you send a UDP packet to an IP address whose MAC is not known it will cause ARP resolution to be started (and not the UDP frame being sent).

ARP informs the owner task, which can then resend the UDP frame when the MAC address is known:

        case TASK_ARP:
            fnRead(PortIDInternal, ucInputMessage, ucInputMessage[MSG_CONTENT_LENGTH]); // read the message content
            switch (ucInputMessage[0]) {                                 // ARP sends us either ARP resolution success or failed
            case ARP_RESOLUTION_SUCCESS:                                 // IP address has been resolved (repeat UDP frame).
                fnSendUDP(MyUDP_Socket, ucUDP_IP_Address, MY_UDP_PORT, (unsigned char*)&ptrUDP_Frame->tUDP_Header, UDP_BUFFER_SIZE, OWN_TASK);
                break;

            case ARP_RESOLUTION_FAILED:                                  // IP address could not be resolved...
                break;
            }
            break;

See also the UDP thread at https://www.utasker.com/forum/index.php?topic=41.0 which explains it in detail.

Regards

Mark

51

NXP^TM M522XX, KINETIS and i.MX RT / Re: 1 UDP socket for server and client?

« on: June 24, 2022, 01:45:02 PM »

Hi Neil

Only 1 UDP socket is needed.
Transmission can take place at any time on the socket.
The socket call-back is used for reception, which can also happen at any time.

The only thing that changes over time with UDP is related to ARP table entries. If the destination address is in the ARP table transmissions take place immediately and if not ARP first has to resolve it; the cal back informs that the content should be repeated once it has resolved. With time ARP entries time out and this needs to be repeated.

Apart from that detail I don't see that the behavior changes (or failures start occurring) over time so I expect problems are likely to be outside of the UDP functionality.

Regards

Mark

52

utFAT / Re: New SD cards stuck in CARD_BUSY_WAIT

« on: May 23, 2022, 08:24:09 PM »

Hi

SD Cards are used mainly n SDHC/SDIO mode and that will be 99.999% the case when inserting them into pieces of equipment like cameras.

In the past I have hear of batches of card that didn't work normally in SPI mode but worked as expected in SDHC mode.

The last change that I made was 2 years ago in order to ensure that a batch of cards that suddenly used a different version of the specification (I believe in SPI mode) could be handled:

30.04.2020 Add option SUPPORT_SDCARD_V1 to allow V+ SD cards to be used

In that mode there is a command that is not supported and so has to be ignored when it fails but I don't see it to be the same case as yours. If it is not enabled you could however give it a try.

Have you tried the "info" command in the SD card menu? This will show the card's CSD register content which gives some details and may show that there is a difference when compared with the cards that have worked.

The SPI mode was developed about 14 years ago and I don't remember the details of the start and stop bit method that was integrated (or whether anything was not respected in the process) but you are welcome to send me a reference card so that I can investigate if you don't find a solution to get the batch operating.

Regards

Mark

53

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

54

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

55

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.

56

µ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

57

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

58

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

59

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

60

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