Recent Posts

Pages: 1 ... 6 7 [8] 9 10
71
µTasker general / Re: How to configure SPI_FILE_SYSTEM to work with serial loader
« Last post by Ray on September 05, 2023, 03:39:22 AM »
This one really has be stumped. 
Yes, the main application when installed by itself, will enumerate the 16Mb SPI_FLASH_W25Q128.
That is the drive with a root directory for an HTTP simple interface so the web folder is on the spi flash chip and works perfectly as a standalone.

The main application when using a serial loader installs at 0x9080  The serial loader hex file confirms everything is in the correct location. 
It feels like the Serial loader is failing somewhere when accessing the spi flash device.   The serial loader enumerates a USB MSD in windows however it is only an empty 1.32 Mb  I'm hoping this is  a clue because I don't believe the chip actually is being accessed.  I use that old windows SDK program usbview.exe to read the setup info. 

The serial loader enumerates MSD but then just hangs, not jumping to the app.   
When I install only the serial loader it continually reboots and enumerates that same false value, seems like a wtd reboot.

also, in kinetis_FLASH.h when EXT_FLASH_FILE_SYSTEM  is defined,  the switch statement has a case  _STORAGE_PARALLEL_FLASH and is calling undefined functions fnWriteParallelFlash(), and fnGetExtFlashAdd().  (causes compile error)

Maybe that is a clue? I just comment out those functions since its about parallel flash not SPI flash



72
µTasker general / Re: How to configure SPI_FILE_SYSTEM to work with serial loader
« Last post by mark on September 05, 2023, 02:56:08 AM »
Hi Ray

I don't see the problem by just looking at the configuration.

If I understand correctly you have an application that uses an external SPI memory as FAT media and a host works with it via USB (USB-MSD). Can your application also access the FAT and can it format it? If it can you can use the W25QXXX.ini from the simulation of the application for the serial loader simulation (by copying it to the serial loader's simulation folder). This may help debug the serial loader (when it has a known formatted FAT in the SPI Flash) to see why this is maybe not recognised as the application does. You could check that both application and serial loader are accessing the content at the same address (for example) when both mount the FAT.

Regards

Mark

73
µTasker general / Re: How to configure SPI_FILE_SYSTEM to work with serial loader
« Last post by Ray on September 02, 2023, 09:23:40 PM »
Let me add the simulator UART debug output:
 uTasker Serial Loader V1.5

===========================

[0x00009080/0x0007ffff]

me = mass erase

bc = blank check

dc = delete code

ld = start load

go = start application

> SD-Card presentAndFormatted       *** added AndFormatted to verify what I was seeing on simulator *  this is a formatted W25QXXX.ini with no code on it

SD JumpToApp(disk_loader-328)        *** I added this just before fnJumpToApplication(1);                              // {3} unconditional jump to application code

No Application (Serial_loader-4413)

Thanks
Ray
74
µTasker general / How to configure SPI_FILE_SYSTEM to work with serial loader
« Last post by Ray on September 01, 2023, 10:43:58 PM »
Hi Mark

On a main application, the SPI_FILE_SYSTEM  based on SPI_FLASH_W25Q128 devices (16MB)  seems to work perfectly as a USB MSD. 
(I needed to commented out   // #define ACTIVE_FILE_SYSTEM    which appeared to mess with my FAT32 format)
Reading and writing files and dragging folders to the DISK seems to be fully operational. 

I've had the serial loader with the SDCARD working, but flash chips are a whole lot better solution for me.
It's time for me to tackle the problem with the serial loader.  First, just treating it as a USB MSD doesn't seem to work.  with the  #defines set like this, it seems to lockup. 

loader.h
#define UTASKER_APP_START     (36 * 1024)
#define UTASKER_APP_END           (unsigned char *)(UTASKER_APP_START + (476 * 1024))
#define _UTASKER_APP_START_   (UTASKER_APP_START + (ROOT_FILE_ENTRIES * 32))

config.h of serial loader
    #define USB_INTERFACE                                                // enable USB driver interface
#define USB_MSD_DEVICE_LOADER                                 // USB-MSD device mode (the board appears as a hard-drive to the host)
   
#define USB_DEVICE_SUPPORT             
#define USB_MSD_TIMEOUT       
#define SPI_FLASH_FAT                                                // SPI flash
#define SIMPLE_FLASH                                             // don't perform block management and wear-leveling
#define FLASH_FAT_MANAGEMENT_ADDRESS     (SIZE_OF_FLASH)
#define DELETE_SDCARD_FILE_AFTER_UPDATE   

#define UTFAT_WRITE
#define UTFAT_LFN_READ                                               // enable long file name read support
#define STR_EQUIV_ON                                                 // ensure that this routine is available
#define UTFAT_LFN_WRITE
#define UTFAT_LFN_WRITE_PATCH
#define RANDOM_NUMBER_GENERATOR
#define UTFAT_RETURN_FILE_CREATION_TIME   

Nothing works, it locks up, but  creates a USB_MSD

UPLOAD_DISK(F:)  1.31 MB free of 1.32MB 

This is incorrect because the flash chip is fully formatted with a folder f:\web and it's lone file when I run the application code.

I think the problem is it's not correctly configured for what it is. 

I have it configured with #define USB_MSD_DEVICE_LOADER
however I don't think this is the proper way for it to be implemented for my use-case.

For the initial programming of a new board, the serial loader should fail with this:  #define _DISPLAY_SD_CARD_NOT_PRESENT() fnDebugMsg("SD-Card not present\r\n")
Jump to the main application, and then the main application has a initialization with formats the new device...and all is well.

I'm confused as to how exactly I configure SPI_FLASH as a MSD for the serial loader?  Is it an "SD Card" or USB Device? 
It seems to to walk the line and be a little bit of both?
I noticed I can't just use USB_MSD and SDCARD_SUPPORT

FYI - when I have a properly formatted W25QXXX.ini  the UART3.txt indicates
> SD-Card presentAndFormatted
No Application

I'd like it to act like a SDCARD and the USB doesn't need to do anything until it jumps to the main application.
Debug is fine with just the UART


Oh, some other details are the linker edits, although I feel I have them correctly setup.

and my K_512_128_BM.ld uses:
MEMORY
{
    FLASH (rx) : ORIGIN = 0x00009080, LENGTH = 0x00080000-0x9080         /* 512k Flash - boot loader */
    SRAM (wx)  : ORIGIN = 0x1fff01f0, LENGTH = 0x00020000-0x1f0          /* 128k RAM with vector size 0x1f0 (488 bytes - maximum for all processors) */
}

SECTIONS
{
  __SRAM_segment_start__   = 0x1fff01f0;
  __SRAM_segment_end__     = 0x2000ffff;
  __Vector_segment_start__ = 0x00009080;                                 /* application start address */
  __Vector_segment_end__   = 0x0000908f;
  __FLASH_segment_start__  = 0x00009090;
  __FLASH_segment_end__    = 0x0007ffff;
Thanks
Ray
75
NXPTM M522XX, KINETIS and i.MX RT / Re: uTasker v2.0.0 doesn't compile on MCUXpresso v11.5.0 (.text LMA overlaps)
« Last post by mark on August 04, 2023, 12:21:01 PM »
Please see thsi thread too:
https://www.utasker.com/forum/index.php?topic=2164.0

76
µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem
« Last post by mark on August 03, 2023, 09:18:59 PM »
I corrected the double "defined" in the previous post (which was of course incorrect).
Regards
Mark
77
µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem
« Last post by Ray on August 03, 2023, 06:19:08 PM »
#if defined defined USER_INFO_MASK   
Actually should be
#if defined USER_INFO_MASK

The copy/paste demon wins again  :)

I'll update and test

Thanks
Ray
78
µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem
« Last post by mark on August 02, 2023, 12:27:06 PM »
Hi Ray

    #if IP_INTERFACE_COUNT > 1 || IP_NETWORK_COUNT > 1                   // {74}
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _TCP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
    #else
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)
        #define _TCP_SOCKET_MASK(uSocket)         (uSocket)
        #define _UDP_SOCKET_MASK_ASSIGN(uSocket)
        #define _UDP_SOCKET_MASK(uSocket)         (uSocket)
    #endif

When used in a single network/single interface environment the masks become dummy.
However I see that when SNMP is used a further USER_INFO_MASK field is used (in order to control multiple SNMP managers).
My suggestion is that the use of the mask for UDP sockets (not TCP sockets) be forced with:

    #if ((IP_INTERFACE_COUNT > 1) || (IP_NETWORK_COUNT > 1))             // {74}
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _TCP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
        #define _UDP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
    #else
        #define _TCP_SOCKET_MASK_ASSIGN(uSocket)
        #define _TCP_SOCKET_MASK(uSocket)         (uSocket)
        #if defined SER_INFO_MASK
            #define _UDP_SOCKET_MASK_ASSIGN(uSocket)  (uSocket &= (SOCKET_NUMBER_MASK))
            #define _UDP_SOCKET_MASK(uSocket)         (USOCKET)((uSocket) & (SOCKET_NUMBER_MASK))
        #else
            #define _UDP_SOCKET_MASK_ASSIGN(uSocket)
            #define _UDP_SOCKET_MASK(uSocket)     (uSocket)
        #endif
    #endif
#endif

Thanks for identifying the issue - presumably I always had a mult-network environment when working with SNMP to have missed this.

Regards

Mark
79
µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem
« Last post by Ray on July 28, 2023, 06:11:35 PM »
Hi Mark,
I stared at that 'M' and while it didn't set off the right alarms for me, it did seem odd.  Yes, that fixed my SNMP_TASK problem and now I am able to use the fnRetry(socket,n) to pull from the queue.

Ah, now that worked, but...  Yes a little more.
This makes sense now:
unsigned char ucSNMP_manager = ((socket >> USER_INFO_SHIFT) & USER_INFO_MASK); // extract the snmp manager information

socket is a 5 bit (max 31 sockets, no socket 0)
Needed to extract
        #define USER_INFO_SHIFT      5
        #define USER_INFO_MASK       0x03                                // 4 users supported
        #define SOCKET_NUMBER_MASK   0x1f                                // single network and interface with up to 4 user functions (USOCKET can be single byte width)
      
      
This is the root cause of my fnSendUDP failure too.   I believe you meant to do something with this preprocessor directive _UDP_SOCKET_MASK(SocketHandle); 
in tcpip.h   (487)    #define _UDP_SOCKET_MASK(uSocket)         (uSocket)
however, it doesn't do anything and allows the top 3 bits to shine through.

I actually solved this by doing this instead:
SocketHandle = (SOCKET_NUMBER_MASK & SocketHandle);

extern signed short fnSendUDP(USOCKET SocketHandle......)
UDP_TAB *ptrUDP = tUDP;
  SocketHandle = (SOCKET_NUMBER_MASK & SocketHandle);
  if ((SOCKET_NUMBER_MASK & SocketHandle)> UDP_SOCKETS){ //(_UDP_SOCKET_MASK(SocketHandle) > UDP_SOCKETS) {                  // {7}
      return INVALID_SOCKET_HANDLE;
  }
  if ((uMemcmp(dest_IP, cucNullMACIP, IPV4_LENGTH)) == 0) {
      return(INVALID_DEST_IP);
  }
      
   By the time we are in fnSendUDP()  no other info seems necessary,
   
   if somehow I haven't thought this completely through, I think you might want me to update the #define _UDP_SOCKET_MASK(uSocket)  (uSocket&SOCKET_NUMBER_MASK)
   
   At this point my traps on all 3 managers are being received without me resorting to forcing any ARP requests outside of the normal ARP algorithm.
80
µTasker general / Re: SNMP Traps not sending timely and/or locking up, appears to be ARP problem
« Last post by mark on July 27, 2023, 10:51:07 PM »
Ray

Check that TASK_SNMP is in ctNodes[] in TaskConfig.h

In addition, make sure that you have no new task with the same name.

    {"MsnMp",     fnSNMP,       SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},

#define TASK_SNMP               'n'                                      // SnMP protocol task

This looks wrong - TASK_SNMP should match the first character of the task's string name.

Try with

    {"nsnMp",     fnSNMP,       SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},

instead!

Regards

Mark

Pages: 1 ... 6 7 [8] 9 10