Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 51 to 75 of 99

Thread: Teensyduino 1.54 Beta #7

  1. #51
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    Paul, is the FlexSPI2 Flash still memory mapped? (Which Address?)
    I ask because of MPU. I'm still trying to find the best setting.

  2. #52
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    MPU:
    To answer my question, there is no other allowed setting that does not lead to the 1.7 second freezes.
    Trying more than 16M results in freezes, *any* other addition within the 0x7 range leads to freezes, regardless of the order - before or after - With the subregion bits set or not. So, the last patch for the MPU is the only allowed config. I've tried them all, I think.
    I tried to enable the background region, tried to remove other questionable settings - all does not help.

    A minor problem. But perhaps this message helps to save time for others who play with the MPU and the 0x7 region. I'll stop that now, as we have a working config.

    For this, I don't need to know if there is flash memorymapping or not.
    Last edited by Frank B; 03-18-2021 at 11:21 PM.

  3. #53
    Member SomeoneFromGermany's Avatar
    Join Date
    Apr 2020
    Location
    Germany
    Posts
    48
    @Paul
    Are you planning to make the teensyduino add-on work with the new arduino IDE 2.0 soon?

  4. #54
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,082
    Yes, eventually, but no, not soon. It's still missing features we need, like Pluggable Discovery.

  5. #55
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,082
    Quote Originally Posted by Frank B View Post
    Paul, is the FlexSPI2 Flash still memory mapped? (Which Address?)
    Today we should only be using FlexSPI2 memory mapping in the range of 70000000 to 70FFFFFF for PSRAM.

    LittleFS uses the IP commands to access flash.

    @Kurt, Defragster, mjs513 - Is anyone still using the early code which accessed flash chips as memory 71000000 to 7FFFFFFF?

  6. #56
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    I guess this means LittleFS is not cached (by hardware) and thus slower than the program(0x6....) flash.
    (And, in this case, the current MPU settings are OK)
    Good to know
    Does LittleFS have it's own caching system? How much memory is used for it?

  7. #57
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    25,082
    Quote Originally Posted by Frank B View Post
    Does LittleFS have it's own caching system?
    Nope, not yet.

  8. #58
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    Shall we try to run it memory mapped?
    I think its adress should be 0x78.. then. 128MB max size. Perhaps we can use an additonal MPU setting once the memory-mapping is enabled? (The more i try with the MPU the more incomprehensible is it to me. Something is wrong there... )

    It would be a small and shared cache for free, and I think the cache does read-ahead for a cache line? That would be a valuable plus.

    Edit: I also don't understand why she's only bitchy in the 7x... range. And even if you don't access this range.. mysterious.
    Last edited by Frank B; 03-19-2021 at 01:57 PM.

  9. #59
    Junior Member
    Join Date
    Mar 2021
    Posts
    15
    Hello everyone,
    I'm new to this forum and want to say Hello and thanks for the nice device (T 4.1).
    I'm working on an application which is sending sensor data to Azure Storage Tables with TLS secured transmission which is now running fine but I had some issues to overcome.
    1) To use TLS the NativeEthernet and FNET library had to be substituted by the latest versions of the master branch of the repositories:
    -https://github.com/vjmuzik/NativeEthernet
    -https://github.com/vjmuzik/FNET

    2) Instead of using the TLS implementation of NativeEthernet library I used the the bear ssl implementation of:
    https://github.com/khoih-prog/EthernetWebServer_SSL
    which worked fine, but needed a little patch for the cores/teensy4/Stream.h file as explained here:
    -https://github.com/khoih-prog/EthernetWebServer_SSL/tree/main/Packages_Patches/hardware/teensy/avr/cores/teensy4

    It seems that these improvements are not yet included in beta7.
    I would be happy if this could be done in the final version.
    Kind regards
    RoSchmi

  10. #60
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    Little reminder (should be done before 1.54 final): https://github.com/PaulStoffregen/cores/pull/540

  11. #61
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    Quote Originally Posted by Frank B View Post
    @Paul, could you please fork i2c_t3 by nox771?
    His last activity on github was 2018. His (great) library needs errormessage if used on T4... there were several questions about it, in the last weeks/months
    https://github.com/PaulStoffregen/i2...45c0d7d3851c3c

  12. #62
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,099
    Quote Originally Posted by Frank B View Post
    ...
    Does LittleFS have it's own caching system? How much memory is used for it?
    There is some small cache per media entry - it seems to be a bitmap for where the next free block might be. That could be improved as it seems not updated dynamically - but filled for use - and not expected to cover all the disk's blocks as it is in a provided buffer of given size that may be too small for 4K or 32K blocks.

    When it comes to storage - directories and files - it is in place across the blocks - not centralized. Doing a directory walk can take 2 or many more seconds (logn times noted in thread) as it has to read "link to link" as provided by the disk data. Then it is read once as needed and ignored.

    Not seeing a 32KB cache block having much use as there is no central storage of cluster or dir data - it is all distributed in a fault tolerant way with the design idea to be efficient without having memory overhead.

  13. #63
    Junior Member
    Join Date
    Mar 2021
    Posts
    15
    Quote Originally Posted by RoSchmi View Post
    Hello everyone,
    I'm new to this forum and want to say Hello and thanks for the nice device (T 4.1).
    I'm working on an application which is sending sensor data to Azure Storage Tables with TLS secured transmission which is now running fine but I had some issues to overcome.
    1) To use TLS the NativeEthernet and FNET library had to be substituted by the latest versions of the master branch of the repositories:
    -https://github.com/vjmuzik/NativeEthernet
    -https://github.com/vjmuzik/FNET

    2) Instead of using the TLS implementation of NativeEthernet library I used the the bear ssl implementation of:
    https://github.com/khoih-prog/EthernetWebServer_SSL
    which worked fine, but needed a little patch for the cores/teensy4/Stream.h file as explained here:
    -https://github.com/khoih-prog/EthernetWebServer_SSL/tree/main/Packages_Patches/hardware/teensy/avr/cores/teensy4

    It seems that these improvements are not yet included in beta7.
    I would be happy if this could be done in the final version.
    Kind regards
    RoSchmi
    Apologies, after a closer look it seems that the needed changes named under 1) are already included in beta 7

  14. #64
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    @Defragster, the prefetches would be useful. I learned now, that there is no automatic prefetch, but I think it prefetches at least the rest of a cache-line.
    Remember, accessing a memory location over SPI takes a really long time. Even more if the interface has to tell the chip the address first.

  15. #65
    Member
    Join Date
    Mar 2021
    Location
    Oceanside, CA
    Posts
    20
    The SD library works on my T3.5 but has a serious latency problem so I would like to try sdFAT. This hasn't really worked at all. I was advised to try Teensyduino 1.54 beta 7. This shows some improvement but still doesn't work.

    For the moment I am trying to just get the Bench example working, then simply creating a file and writing to it. The Bench example will compile and run if the chipSelect is changed to BUILTIN_SDCARD and the following line is commented out:
    // cout << F("Card size: ") << sd.card()->cardSize()*512E-9;

    The resulting run, however, is unable to access the card with the following result:

    Code:
    Use a freshly formatted SD for best performance.
    
    Type any character to start
    chipSelect: 254
    FreeStack: 255464
    begin() failed
    Do not reformat the SD.
    No card, wrong chip select pin, or wiring error?
    SdError: 0X1,0X0

  16. #66
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,099
    Quote Originally Posted by choochoo22 View Post
    The SD library works on my T3.5 but has a serious latency problem so I would like to try sdFAT. This hasn't really worked at all. I was advised to try Teensyduino 1.54 beta 7. This shows some improvement but still doesn't work.

    For the moment I am trying to just get the Bench example working, then simply creating a file and writing to it. The Bench example will compile and run if the chipSelect is changed to BUILTIN_SDCARD and the following line is commented out:
    // cout << F("Card size: ") << sd.card()->cardSize()*512E-9;

    The resulting run, however, is unable to access the card with the following result:
    ...
    That example is in the SdFat folder: ...\hardware\teensy\avr\libraries\SdFat\examples\b ench\bench.ino

    As noted the features and functions of SD.h have been mapped to use the SdFat code as replacements.

    There are sample and code in the SdFat examples like that one that directly use the SdFat rules and expectations and won't mix with SD.H usage. Those samples should work in general - but use the requirements of that code base which IIRC does not use BUILTIN_SDCARD the same way.

    To upgrade SD.h just use the same code as before with the newer TeensyDuino 1.54 Beta. Going into SdFat\examples uses that and its rules directly - and not SD.h compatible.

  17. #67
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,099
    Quote Originally Posted by Frank B View Post
    @Defragster, the prefetches would be useful. I learned now, that there is no automatic prefetch, but I think it prefetches at least the rest of a cache-line.
    Remember, accessing a memory location over SPI takes a really long time. Even more if the interface has to tell the chip the address first.
    I suppose no doubt it could help pre-reading and then not needing wait time for sequential addressing requests. Notes were based on the likely hood it would purge and fill the cache with read once data, voiding the data cache for any other effective usage.

    If enabled the LFSIntegrity code might show a difference in some timed operations where the read ahead could help - perhaps doing the DIR Listings or file count verify where it walks the dir tree. It might also cause a wait for requested data while it busies the processor reading beyond the point of interest when the next read is requested?

  18. #68
    Member
    Join Date
    Mar 2021
    Location
    Oceanside, CA
    Posts
    20
    OK, so, gave up on using sdFat as even the examples don't work. Going back to SD and try the newer Teensyduino as below:

    Quote Originally Posted by defragster View Post
    ...To upgrade SD.h just use the same code as before with the newer TeensyDuino 1.54 Beta....
    Now the application that was working fine before is broken:

    Code:
    Arduino: 1.8.13 (Windows 10), TD: 1.54-beta7, Board: "Teensy 3.5, Serial, 120 MHz, Faster, US English"
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `File::whoami()':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/FS.h:84: undefined reference to `Serial'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `SDFile::whoami()':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD\src/SD.h:71: undefined reference to `Serial'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `loop':
    
    C:\Users\Rick\Documents\Arduino\RX_Snoop_V2-1/RX_Snoop_V2-1.ino:301: undefined reference to `Serial'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\sketch\RX_Snoop_V2-1.ino.cpp.o: In function `setup':
    
    C:\Users\Rick\Documents\Arduino\RX_Snoop_V2-1/RX_Snoop_V2-1.ino:227: undefined reference to `Serial'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721\libraries\SdFat\SdCard\SdioTeensy.cpp.o: In function `SysCall::yield()':
    
    c:\users\rick\documents\arduino\libraries\sdfat\src\common/syscall.h:90: undefined reference to `yield'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(analog.c.o): In function `analogRead':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/analog.c:484: undefined reference to `yield'
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/analog.c:515: undefined reference to `yield'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(pins_teensy.c.o): In function `delay':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/pins_teensy.c:1228: undefined reference to `yield'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(usb_serial.c.o): In function `usb_serial_write':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/usb_serial.c:218: undefined reference to `yield'
    
    C:\Users\Rick\AppData\Local\Temp\arduino_build_365721/..\arduino_cache_248229\core\core_576b67285ecb01e18963173d351aed2d.a(main.cpp.o):C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy3/main.cpp:54: more undefined references to `yield' follow
    
    collect2.exe: error: ld returned 1 exit status
    
    Multiple libraries were found for "SD.h"
    
     Used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SD
    
     Not used: C:\Program Files (x86)\Arduino\libraries\SD
    
    Multiple libraries were found for "SdFat.h"
    
     Used: C:\Users\Rick\Documents\Arduino\libraries\SdFat
    
     Not used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat
    
     Not used: C:\Users\Rick\Documents\Arduino\libraries\arduino_47876
    
    Error compiling for board Teensy 3.5.
    
    
    
    This report would have more information with
    "Show verbose output during compilation"
    option enabled in File -> Preferences.
    So trying to go back to something that was working. Not sure of the prior Teensyduino version but the only current install option seems to be 1.53. Unfortunately that won't install. It keeps asking for where to install it and no choices seem to be acceptable. The "Next" button is greyed no matter what directory is selected.

    Click image for larger version. 

Name:	Teensyduino install.jpg 
Views:	23 
Size:	41.3 KB 
ID:	24157

    To get back to something that works, do I need to uninstall everything and start over?

  19. #69
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,099
    @choochoo22 - installing older versions over newer isn't expected to work. Newer versions know what changed and can accommodate - older versions don't know what newer versions have added/changed.

    Best would be to work through issues with SD.H using the SdFat as found in TD 1.54 b7. There may be unfound issues and they need to get resolved before

    One thing is that this should be removed because the desired version is installed with beta 7:: Used: C:\Users\Rick\Documents\Arduino\libraries\SdFat

    Seeing only the errors doesn't offer much chance to help - though it seems there are fundamental issues in the build and install as Fresh Arduino IDE and TD 1.54b7 would provide - many of those errors seem to be unrelated to anything that the change for SD to use SdFat.
    > yield should have no issues
    > Serial should have no issues

    It may help to do a clean install of IDE 1.8.13 and then TeensyDuino 1.54 b7 if such odd errors aren;t resolved using the correct libraries.

  20. #70

  21. #71
    Member
    Join Date
    Mar 2021
    Location
    Oceanside, CA
    Posts
    20
    Quote Originally Posted by defragster View Post
    ...It may help to do a clean install of IDE 1.8.13 and then TeensyDuino 1.54 b7 if such odd errors aren;t resolved using the correct libraries.
    Thanks. I reinstalled IDE and Teensyduino 1.53 and things went back to where they were, the sketch works but with an occasional SD write latency problem.

  22. #72
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,626
    In case an upgrade to a newer toolchain is still considered here an observation which might help debugging:

    This

    Code:
    #include "Arduino.h"
    #include <string>
    
    void setup()
    {
        std::string zahlString = std::to_string(42);
    }
    
    void loop()
    { 
    }
    compiles without problems with GCC 9.3 and TD 1.53, but generates the following error with the current core files

    Code:
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(string-inst.o):(.ARM.exidx.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj[_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERjj'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.extab.text.__cxa_begin_catch+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_catch.o):(.ARM.exidx.text.__cxa_begin_catch+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.__cxa_begin_catch'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text._ZL21base_of_encoded_valuehP15_Unwind_Context+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZL21base_of_encoded_valuehP15_Unwind_Context'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.extab.text.__gxx_personality_v0+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o):(.ARM.exidx.text.__gxx_personality_v0+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.__gxx_personality_v0'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.extab.text._ZN10__cxxabiv111__terminateEPFvvE+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZN10__cxxabiv111__terminateEPFvvE+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN10__cxxabiv111__terminateEPFvvE'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZN10__cxxabiv112__unexpectedEPFvvE+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN10__cxxabiv112__unexpectedEPFvvE'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_terminate.o):(.ARM.exidx.text._ZSt10unexpectedv+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZSt10unexpectedv'
    c:/toolchain/gcc/gcc-arm-none-eabi-9_3-2020-q2/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(vterminate.o):(.ARM.extab.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x0): additional relocation overflows omitted from the output
    collect2.exe: error: ld returned 1 exit status
    Looks like it was introduced with commit "dc56788 Changes to support HAB (thanks dresden-fx)" from 2020-10-18 see https://github.com/PaulStoffregen/co...04356bda7e2a7e

  23. #73
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    @Paul: Can you make a beta #8?

  24. #74
    Senior Member
    Join Date
    Oct 2015
    Location
    Vermont, USA
    Posts
    312
    Is there a notional schedule for releasing 1.54? It's been brewing since October...

    The switch to the Greiman SD is such a game changer. It's so much better than the kludge that I (and my users) have been living with. Because it's so much better/cleaner, I quickly updated my libraries to use the new SD implementation in these beta Teensyduino(s). But, I've been holding off releasing my updated libraries until 1.54 comes out of beta. Is there a vision for when 1.54 might be released?

    If it's still going to be months-and-months, I'll have to go and re-insert my kludged SD code so that I can release other unrelated updates. Ick.

    Chip

  25. #75
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    9,334
    Last version of MPU settings (Pullrequest is still open)
    https://github.com/FrankBoesing/core...startup.c#L222

    Now all regions are minimum, which is the recommended setting. In addition, this would allow a better trapping of accesses to unused areas.
    Last edited by Frank B; 04-02-2021 at 01:11 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •