Recent Posts

Pages: [1] 2 3 ... 10
utFAT / Re: Latest Version
« Last post by neil on January 02, 2022, 02:10:45 PM »
Hi Mark,
  Many thanks  :)

Best Regrards
utFAT / Re: Latest Version
« Last post by mark 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 (for Kinetis and STM32) contains changes up to 2016, whereby the module is essentially HW-independent and so can be used with any processor.


utFAT / Latest Version
« Last post by neil on January 01, 2022, 03:14:20 PM »
Hi Mark,
  Happy new year... And hope 2022 is good :)

  looking at the version of my ufat I see its:  11.07.2014 utFAT2.0   . Is this the latest version? If not how can I update this?

Best Regards

STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« Last post by mark on December 28, 2021, 07:38:50 PM »

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?


STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« Last post by TeeYi on December 28, 2021, 07:35:59 AM »
Hi Mark,
    Thanks for your reply.
    I already found the problem which cause the firmware halt (when call this function fnCheckNewCode(&file_header)). Basically it cause by stack overflow, and it can be solved by increase the stack size (in .lcf file)

define symbol __ICFEDIT_size_cstack__ = 0x400;

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.


STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« Last post by mark on December 26, 2021, 02:07:55 AM »

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).


I am using MK60DX256VLL10 in a circuit. After soldering the controller onto the designed board, I tried to download my code into the controller using Ulink Pro Debugger using Keil MDK. But i encounter "Kinetis Device is Locked. Do you want to unlock it? Mass erase will be executed" to which I press OK. After few seconds, "Invalid ROM table" appears and erase is not performed.

To be cear, the same code is used in another board where same controller is used and in that board, I am able to doanload my code wihtout any "lock isssue" or "invalid rom table" issue.
STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« Last post by TeeYi on December 14, 2021, 03:24:23 PM »
Hi Mark,
    Thanks for your clarification.

    By using Segger J-Flash, I manage to combine the both file & program on the MCU. But it still not working.
    After that by using IAR, I try to debug on the uTaskerBoot which I found two problem on (uTaskerBootLoader.c):

1)   The firmware never run the " start_application(UTASKER_CODE_START) " when compile for STM32, so I add defined _SMT32  as
       as below for the compiler.

#elif defined _STM32 || defined _HW_AVR32 || defined _RX6XX || defined _KINETIS || defined _LM3SXXXX || defined _LPC17XX || (defined _M5223X && (defined _GNU || defined _COMPILE_IAR)) // {14}{17}{19}{20}{21}
    #if !defined _WINDOWS
    start_application(UTASKER_CODE_START);                               // jump to the application

2) when the program run  [ if (fnCheckNewCode(&file_header))], it will cause HardFault exception
    static void irq_hard_fault(void)
   I attached the print screen (IAR) for your reference.

   When I change the routine as below,

static int fnCheckNewCode(UPLOAD_HEADER *file_header)
    return 0;
      After compile again & combine both file (uTaskserBM and uTaskerBoot), my board success boot up and running my program.
      Please advice how to solve the problem for fnCheckNewCode(UPLOAD_HEADER *file_header) routine.
      For your information, I am using SMT32F407ZET6 .
      Thanks & best regards.
STTM STM32 and STR91XF / Re: STM32 uTaskerBoot Project
« Last post by mark on December 12, 2021, 11:03:16 PM »

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.



Pages: [1] 2 3 ... 10