Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - mark

Pages: 1 ... 3 4 [5] 6 7 ... 218
61
NXPTM 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



62
NXPTM 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

63
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




64
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


65
NXPTM 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

66
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

67
µ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

68
USB / Re: USB when moving from MK66 to MK24
« on: February 03, 2022, 05:12:28 AM »
Hi

Beware that USB0 on the K66 and K24 is a Full Speed USB controller (12Mb/s) and USB1 is a high speed USB controller (480Mb/s) and so if you have moved from USB1 to USB0 you need to make sure that you use the correct USB interface (0 rather than 1) when opening it
Code: [Select]
tInterfaceParameters.ucUSB_controller = 0;and also that you specify that its endpoint characteristics are suitable for FS USB (eg. maximum bulk endpoint size is 64 bytes rather than 512 bytes).

It may be that it is enumerating but the PC recognises that its descriptors are not suitable and so shows a configuration error.

Regards

Mark

69
NXPTM M522XX, KINETIS and i.MX RT / Re: uTasker v2.0.0 doesn't compile on MCUXpresso v11.5.0 (.text LMA overlaps)
« on: February 03, 2022, 03:20:47 AM »
Hi Caleb

I only installed V11.5.0 a couple of days ago but did see this error when trying to use its compiler and the GCC makefile build (so reverted back to the previous version to avoid it until studied).
What looks to be happening is that the new compiler libraries add something that wants to be in a section called LMA but, since there is no such section specified in the linker script file, the linker is trying to place this section either partly on top of itself or on top of other things and thus the overlap.

It means that the linker scripts used by GCC and MCUXpresso projects (when using this compiler version) will need to add such a section.

Taking a slightly closer look I don't know that it is a section but something different in the linker script requirement since it looks like .text and .rodata are being placed at the same location. There are various mentions of this and how to fix it - eg. https://programmerall.com/article/14172010184/ but a first quick try didn't help.
Possibly there is something that is not correct in the original linker script that the previous versions of the compiler/linker were tolerant of but now this needs to be solved correctly (?)
I'll study more but in the meantime I am also using the V11.4 to enable operation.

Regards

Mark

70
utFAT / Re: Latest Version
« on: January 01, 2022, 09:15:21 PM »
Hi Neil

Happy New Year to you too!!

The present working version has these changes:

    11.07.2014 utFATV2.00
    05.08.2014 Correct long file rename end of directory save            {1}
    15.08.2014 Corrected =! to !=                                        {2}
    29.08.2014 Correct creating additional directory clusters            {3}
    03.09.2014 Remove fnCreateFile(), fnSetFileLocation() and fnInsertLFN_name() parameter {4}
    03.09.2014 Reset any deleted location markers when moving to next paragraph {5}
    06.10.2014 Correct brackets in fnExtractLongFileName()               {6} [utFATV2.01]
    30.11.2014 Add SPI_FLASH_FAT (run utFAT in external SPI based flash)
    03.12.2014 Don't display hidden files unless the HIDDEN_TYPE_LISTING flag is set and expert functions enabled {7}
    04.12.2014 Add FLASH_FAT (run utFAT in internal flash)
    11.12.2014 Add fnResetDirectories() for use when a disk is re-mounted and delete valid sector after re-formatting {8}
    13.12.2014 Ensure that the sector buffer is synchronised when writes are made using fnWriteSector() {9}
    22.01.2015 Add option to return a file's creation time and date in its file object {10}
    06.10.2015 Only when LFN is disabled: Corrected _utOpenDirectory() directory location returned when opening to write new files, plus reuse deleted directory space when possible {11}
    30.10.2015 Added emulated FAT support (FAT_EMULATION)                {12} [utFATV2.02]
    16.11.2015 Ensure that EMULATED_FAT_LUNS is available                {13}
    17.01.2016 Add utFileAttribute() - allows changing file attributes (not directories) {14}
    17.01.2016 Reset long file name counter when skipping hidden files   {15} [utFATV2.03]
    24.04.2017 Handle USB_MSD_REMOVED when memory stick is removed       {16}
    09.07.2017 Allow renaming a file to a different directory location   {17}
    14.07.2017 Avoid matching directories when not complete path handled {18} [utFAT2.04]
    18.12.2017 Allow emulated FAT to be used together with other disk types than SD card {19}
    02.03.2018 Added block read option                                   {20}
    11.03.2020 Added i.MX RT support
    12.03.2020 Allow FAT32 info sector use on all media                  {21}
    13.03.2020 Correct FAT16 cluster boundary detection                  {22}
    13.03.2020 Allow up to 64k clusters on all media                     {23}
    30.04.2020 Add option SUPPORT_SDCARD_V1 to allow V+ SD cards to be used
    01.07.2020 Remove DISK_NOT_PRESENT flag when mounting                {24}
    12.08.2020 Correct FAT size when SPI flash used with page size 256   {25}
    12.08.2020 Backup and rewrite physical sector content of SPI flash that have sector sizes of multiples of 512 bytes {26}
    20.08.2020 Allow directory creation when a real storage medium is used together with emulated FAT {27}
    28.01.2021 Initialise local data using uMemcpy() to avoid GCC optimisation problem with unaligned data {28}

Access to the working version is possible with a support subscription (extension) if you are using the project commercially.

Otherwise the open source version on GitHub at https://github.com/uTasker/uTasker-Kinetis (for Kinetis and STM32) contains changes up to 2016, whereby the module is essentially HW-independent and so can be used with any processor.

Regards

Mark

71
STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« on: December 28, 2021, 07:38:50 PM »
Hi

That is strange since the project uses a stack pointer at the top of SRAM and not the stack size that is given in the linker script file (this allows its stack to automatically have the size of all unused RAM).
Possibly it is the specific IAR version overwriting this?

Regards

Mark

72
µTasker general / Re: Kinetis Device is Locked.Do you want to unlock it? Mass erase will be executed.
« on: December 26, 2021, 02:11:01 AM »
Hi

I my experience the message about the device being locked and other such message (when not expected) are due to a problem with the debugger communicating with the HW.

If the same debugger setup works on different boards you need to check the JTAG or SWD connection carefully for differences/errors. Also ensure that the debugger is set for the correct JTAG or SDW mode, depending on what the HW previews it to use.

Regards

Mark

73
STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« on: December 26, 2021, 02:07:55 AM »
Hi

I am sorry that i didn't respond earlier:

1. I also found that the jump was not enabled for STM32 and the new dependency is correct.

2. I don't see the code causing the hard fault but I assume that it is due to the routine checking the flash content at an incorrect address/range (if you look at the call stack you can see the routine that resulted in the error - and also if you single step out of the hard fault handler (in disassembly mode) it will return to the instruction causing the error. You can see what address the instruction is using and verify that the range set up for the check is suitable for the part in question (like uFILE_START and UTASKER_APP_START).

Regards

Mark

74
STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« on: December 12, 2021, 11:03:16 PM »
Hi

When this command is executed there is the message "Boot code too long (> 1000). Terminating" and so no output content is generated.
The problem is that the "uTaskerBoot.bin" is 50k in size and the command tried to add the second file "uTaskerBM.bin" at the location 0x1000, which is not possible since this would be in the middle of the first file.

The basic issue is that the boot loader is being built with a linker script that locates the reset vector at the 0x08000000 but he reset of the code at 0x080c000 and so leaves a large gap between the two which makes the file large (this can be seen by opening the binary file in a hex editor and shows a large amount of 0x00 being inserted).

I believe the line in the linker script doing this is:

define symbol __ICFEDIT_region_CODE_start__ = 0x0800c000;

and is designed for use by programs that leave two flash sectors free for use by the parameter system. Since the boot loader doesn't use the parameter system this line is not appropriate and if you remove it it will presumably then generate loader code that is all in the first flash sector (and small).


The IAR out format is ELF format, which is not generated. You will therefore need to use a different loading technique than IAR's (which only allows loading files that it has created). ST Micro has a utility that is often used for this and, once the loader and the initial application are installed subsequent uploads can be performed by the application's loading method.

Regards

Mark


75
STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« on: November 29, 2021, 05:12:28 PM »
Hi

I have checked in an IAR9 project for STM32.

Regards

Mark

Pages: 1 ... 3 4 [5] 6 7 ... 218