Forum Rule: Always post complete source code & details to reproduce any issue!
Page 26 of 38 FirstFirst ... 16 24 25 26 27 28 36 ... LastLast
Results 626 to 650 of 926

Thread: Teensy 4.0 First Beta Test

  1. #626
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,020
    @Paul, can we talk about the memorymap?
    I think it may be better to move DMAMEM behind the heap. Heap-start: 0x20200000, DMA-start 0x20200000 + SIZEOF(OCRAM) - SIZEOF(DMAMEM) ( with correct granularity)
    Problem is (I think, if I understand that correctly!!!), the MPU can divide a region into 8 subregions with eqal size only.

    So if we place DMAMEM before Heap, and let's say DMAMEM is 153600 Bytes, and Heap starts after that, the first part of heap has to have the same cache-setting as DMA.
    If we reverse that, and place DMAMEM after Heap, we have basically the same situation, but if we move the region a bit down we can have the DMAMEM as intended and only a small part of the upper heap (which is not used with a bit luck) with wrong cache-setting.

  2. #627
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,002
    Quote Originally Posted by Frank B View Post
    @Walter: IRQ_SOFTWARE is already defined (70)
    Yes, I know, but contrary to T3x, all ISR are by default unused ( and blink fast).

  3. #628
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,167
    TEMPERATURE MONITORING in CORE FILES

    First don't panic, unless the chip get over 95C nothing chip won't restart automatically. Attached is a zip with the changes to the core to get the tempmonitor into the core to start automatically. Then from any sketch you just call tempmonGetTemp() and you get the current core temp. If you want to give it a try.

    tempMonCore.zip

    There are only 2 functions, init and gettemp.

    Up to the boss if he wants to incorporate this piece into the core. As for what to do when the panic temp is hit, I will leave it up to FrankB

  4. #629
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,020
    LOL, that' Pauls decision (I can help to write some code)

    I thought about that, and I think - if we run at high frequencies - we should remove loops like while(1); from the core (there are a few places) and switch-off* instead.
    While(1); without temperature-monitoring may be very bad... with temperature monitoring we should at least make sure that the temperature does not rise more after a "panic"-event. My idea was to issue a reset (this will work with a crashed app, too) when "panic" and switch off* after reset.

    mjs, I'll look at your zipfile thank you!

    Edit:
    *or run while(1); with a very low frequency

  5. #630
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,167
    with temperature monitoring we should at least make sure that the temperature does not rise more after a "panic"-event. My idea was to issue a reset (this will work with a crashed app, too) when "panic" and switch off after* reset.
    That's the beauty of the temp monitor. If the panic temp is exceed it will auto reset. On reset it the PMU_MISC1 register identifies the cause of the reset including temperature. So, if you test for that on startup then you can tell it to "switch off". Like you said that's up to Paul. I am trying to get things crossed off his giant list of things to do

    Oh, in case you are wondering you don't need to do a read temp for it work, it does it automatically in the background.

    Maybe that list should be broken up to a couple of lists. Whats done and whats left to do. Might be easier to go through.

    Respectfully
    Mike

    EDIT:
    *or run while(1); with a very low frequency
    Throttling?

    EDIT2: Don't need to replace analog.c = put it in there by accident.

  6. #631
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,965
    Quote Originally Posted by Frank B View Post
    @Paul, can we talk about the memorymap?
    Just to let you know, today I'm having to deal with some business stuff - less time for dev work today. Hope to be back up to speed early tomorrow.

    I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou. I have a 5th board where Serial7 isn't connected - don't know why yet.

    These breakout boards have a place to plug in an audio shield. But when I designed the breakout board, I didn't plan the heights too well, so the audio board's headphone jack can't be plugged in with the Teensy 4 in place (this will be pretty easy to see when you get the boards). So we're sending you an audio board and a pair of the tall headers, so you can raise the audio board up enough to be able to actually get the headphone plugged in. There's a slide switch which controls some mux chips, so either SAI1 or SAI2 can be connected to the audio shield.

    The SD card pins of the audio shield (11, 7, 14) route to the SPI pins (11, 12, 13), so this should also give a convenient way to test SD cards with SPI access.

    The breakout board also has 2 pogo pins for the 2nd USB port, going to a USB host connector. USB host power is from VIA through a TPS2055A current limiter, so hopefully you can hot-plug USB devices without crashing Teensy 4's power.

    I have not actually tested the audio connections or USB stuff yet - only the serial port signals have actually been tried. Hopefully I didn't mess this board up, cause we're sending to you now.


    On the memory, the main reason to have the static DMA buffers first is the heap grows upward. I believe _sbkr() is supposed to cause malloc and new to not do more allocations when they reach the limit.... so many it's safe to put static buffers after the heap? But it still *feel* strange. I need a little time to think on this.

  7. #632
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,020
    Thank you, awesome.

    Memory: Isn't the stack behind the heap on the other boards? Not sure if I remember correctly.

  8. #633
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,002
    Quote Originally Posted by PaulStoffregen View Post
    These breakout boards have a place to plug in an audio shield. But when I designed the breakout board, I didn't plan the heights too well, so the audio board's headphone jack can't be plugged in with the Teensy 4 in place (this will be pretty easy to see when you get the boards). So we're sending you an audio board and a pair of the tall headers, so you can raise the audio board up enough to be able to actually get the headphone plugged in. There's a slide switch which controls some mux chips, so either SAI1 or SAI2 can be connected to the audio shield.
    @those_who_get_the_breakout_board
    If you are interested in a SAI test program, I put my (running) program to GitHub https://github.com/WMXZ-EU/basicSAI
    (it is 32 bit, but I trust you know how to change to 16 bit)

  9. #634
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,020
    I am interested I think we can parts of that for SPDIF? I've bought a new SPDIF-DAC to test the T4.

  10. #635
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,167
    I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou.
    WOW. Thank you Paul. Pleasant surprise.

  11. #636
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,802
    Thanks Paul,

    Will start testing some of the bottom pins when it arrives

    I just checked in my changes to SPI for transfer(buf, retbuf, cnt)

    I updates the delay between bytes to be half the value computed for the speed. At least that is what looks like it should work properly. The good news is that looks correct, the bad news is that it probably slows down single byte transfers... But that is expected as same as T3.x...

    Not sure yet which thing to look at next:

    a) Update Transfer16 should be simple... Just need to update TCR.FRAMESZ - question to self is to change once and back after the transfer16, or cache the information and only change when needed...

    b) Play with CS pin, to see how it works (can I control it it and use for DC pin?

    c) SPI.transfer - Async version ---Would help to see a working DMA operation... How close is it to T3.x?

    d) SerialX - Try out the half duplex support - maybe try out Dynamixel Servos...

    e) Maybe something completely different? Has anyone tried playing with the Flex Pins? Like make an SPI setup or Wire or Serial?

    Now back to playing

  12. #637
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,167
    TALKIE LIBRARY

    Made a minor updates and put pin 5 into the .cpp if you specify a propshield is attached. Only example updated is toms_diner. If you want to give it a try its on GitHub: https://github.com/mjs513/WIP

  13. #638
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,783
    Quote Originally Posted by manitou View Post

    Sigh, T4 won't load at all this morning. After pushing program button, i get slow flashing red LED, but no progress bar and uploads fail. no /dev/ttyAMC0. Holding down program button for 13 secs, gets steady red LED for a few seconds ... but doesn't fix anything

    It was working last night with beta7. I think the last thing i did was I2C test of setClock() with scope -- looked good at 100k, 400k, and 1mhz.

    5v on Vin, 3.3v on 3v3 pin.

    I've tried on other desktops, other USB cables. T3* stuff still works.
    Well, i hooked T4 up to my laptop (linux 1.8.8 beta5), and it was able to upload and run . (I still have to push program button after load to get it to run and /dev/ttyACM0 to appear)... maybe it's something to do with beta7 and my T4? though i ran several sketches under beta7.

    i'll do my builds on my laptop, til i feel brave enough to go back to desktops...

  14. #639
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,344
    I got 4 of the breakout boards built. Robin's going to send them out today. Kurt's went yesterday. Boards are shipping today to you, mjs513, defragster & manitou.
    Quote Originally Posted by mjs513 View Post
    WOW. Thank you Paul. Pleasant surprise.
    I'll second that and add a -

    @WMXZ - Ordered a pair of the PJRC PT8211 kits with my Beta T4 assuming they be good for testing - Will they be useful against your basicSAI code? - of course with a dedicated Audio Board …

    Found an old Panasonic VCR remote [with understood codes] and the IR_recv code is of course still working from last upload last night.

  15. #640
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,020
    I think I have some PT8211 (at least their China pendants..forgot the part number) too, Walter.
    Might be faster from Germany..

  16. #641
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,802
    Looks like the gap timing between transfers still needs some work... Running a quick test program to test some of the different SPI transfers including SPI.transfer16().

    I implemented the transfer16, which you can see in the screenshot:
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	13 
Size:	56.1 KB 
ID:	15549

    You can see how the 16 bits output as one unit and way to big of a gap between transfers. Asked for 30mhz transfer speed...

  17. #642
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,783
    TRNG

    T4 has a hardware random number generator, it is quite complex and slow, and documentation is subject to NDA. See earlier post
    https://forum.pjrc.com/threads/54711...l=1#post193965
    The NXP SDK has some examples using the TRNG, and I was able to mostly port the code to Teensy 4. There are lots of statistical configuration parameters -- I just took the defaults (whatever they may be). The TRNG produces 512 bits every 13470 us -- much much slower than the T3.5/3.6 TRNG, so the T4 TRNG is best suited for generating a random seed for a PRNG. I haven't done the NIST statistical tests for randomness (yet), but I did calculate byte-entropy on 16K TRNG bytes , getting 7.98. 16 KB of random() bytes has entropy of 7.94

    The SDK TRNG example with its configured statistical parameters takes 212856 us to generate 512 random bits.

    EDIT: I ran some randomness stat tests on 1MB of TRNG data. Results weren't that good, one will need to configure TRNG rather than taking POR values. (randomness tests of SDK EVKB TRNG data were acceptable).
    Last edited by manitou; 01-09-2019 at 01:42 PM. Reason: entropy correction

  18. #643
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,783
    Quote Originally Posted by Frank B View Post
    If someone wants to know how to switch the IMXRT off completely, mail me.. tested, works... but I don't write that here, because if you have no long delay before that, there is currently no way to switch it on again, as it will immediately switch off when it runs the program with the command ... so..it's risky. have not tried if the 13-seconds reset works in this case..

    edit: ok, 13 seconds reset still works, so i think it's the bootloader-chip which stays alive and monitors the button.

    edit: and this confirms the 13-seconds reset works, too



    Frank can you email me your code? Usually, with scary sketch, i add an INPUT_PULLUP pin that I spin on at the start of the sketch, and won't "start" til the pin is pulled low.

    Actually, what i'm interested in is the power implications. Can you measure power (milliamps) for your T4 running blank sketch, and then run your shutdown sketch and measure power when IMRXT is off. Then we know the overhead power used by the bootloader etc. on the PCB.
    Last edited by manitou; 01-09-2019 at 12:27 AM.

  19. #644
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,344
    Quote Originally Posted by manitou View Post
    Frank can you email me your code? Usually, with scary sketch, i add an INPUT_PULLUP pin that I spin on at the start of the sketch, and won't "start" til the pin is pulled low.

    Actually, what i'm interested in is the power implications. Can you measure power (milliamps) for your T4 running blank sketch, and then run your shutdown sketch and measure power when IMRXT is off. Then we know the overhead power used by the bootloader etc. on the PCB.
    Frank sent me a copy, I can PM to you if Frank is offline.

    I get 86.3 mA with blank sketch, I may have put yield() in the loop() cycle.

    Frank's Sketch runs just over 87 mA printing for 10 seconds it then powers off to 28 mA.

    It then ignores button push … not sure where that power is going ...

    Repowering goes back to 87 mA - then after countdown is sitting at 28.1 mA.

    I had two other Teensy's on breadboards with common GND and unplugging them shows it sitting at 28.3 mA

    That is the first I ran the sketch - it counts down 10 seconds - just did a Verify sketch and powered up with button and it uploaded IRrecvDemo no problem - Funny it was showing 100 mA before putting power back to BBoard to the IR device (with a blue pilot light LED) and it dropped to 98.7 mA.

  20. #645
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,783
    Quote Originally Posted by defragster View Post
    Frank sent me a copy, I can PM to you if Frank is offline.

    I get 86.3 mA with blank sketch, I may have put yield() in the loop() cycle.

    Frank's Sketch runs just over 87 mA printing for 10 seconds it then powers off to 28 mA..
    Thanks. Those numbers look good, suggesting MCU consumes 59 ma. Spec says 0.11ma/MHz, so for 600MHz about 66ma

  21. #646
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,344
    Quote Originally Posted by manitou View Post
    Thanks. Those numbers look good, suggesting MCU consumes 59 ma. Spec says 0.11ma/MHz, so for 600MHz about 66ma
    <edit> - sketch not the evil - DO NOT RUN THIS SKETCH ?!?!?!?!?!?!
    I think the issue may have been the way power checking was forcing the device to restart.
    I just revisited the sketch a bit more - making sure it returned the F_CPU to 600 - also the RTC started to make sure Millis clocks right - and it had Serial running as well.

    This sketch boots to ~83 mA then drops to 58 mA
    Code:
    extern "C" uint32_t set_arm_clock(uint32_t frequency);
    void setup() {
      S e r I a l .begin(9600); // This line broken on purpose 
      while ( !Serial && millis() < 800 ) ;
      Serial.println("F_CPU_ACTUAL");
      Serial.println(F_CPU_ACTUAL);
      delay(5000);
    set_arm_clock(300000000);
      Serial.println("F_CPU_ACTUAL");
      Serial.println(F_CPU_ACTUAL);
    }
    void loop() {
    }
    and prints::
    F_CPU_ACTUAL
    600000000
    F_CPU_ACTUAL
    300000000
    Not Funny but ODD - after running that sketch I pull USB and replug - it prints speed drop and then only consumes 27 mA? I rewrote the sketch to end with 600 MHz - and it went to 37 mA … but doesn't seem to be running ???

    Just did a 15 second hold ? Light Red went to solid RED for some seconds then Off and T4 is Back - but not running Right yet?

    Paul - here is Verbose TLoader in case it shows something? SetArmClock_XXX.txt

    Uploaded a MinBlink after another 15 second reset and T4 Debugt output just shows:
    status = 00370080
    status = 00370080
    status = 00370080
    status = 00370080
    status = 00370080
    status = 00370080
    status = 00370080
    status = 00370080
    status = 00370080
    Uploaded a non-printing min blink - never gets to Setup - here is debug output:
    ***********IMXRT Startup**********
    test 1 -1234567 3
    CCM_ANALOG_PLL_USB1=80003000
    enable USB clocks
    CCM_ANALOG_PLL_USB1=80003040
    Increasing voltage to 1250 mV
    need to switch to alternate clock during reconfigure of ARM PLL
    USB PLL is running, so we can use 120 MHz
    Freq: 12 MHz * 100 / 2 / 1
    ARM PLL=80002042
    ARM PLL needs reconfigure
    ARM PLL=80002064
    New Frequency: ARM=600000000, IPG=150000000
    USB reset took 5 loops
    analogInit
    usb_cdc_line_coding, baud=0
    before C++ constructors
    after C++ constructors
    before setup
    Closes T_sermon and then saw this as debug port output:
    usb_cdc_line_coding, baud=0
    usb_cdc_line_coding, baud=115200
    usb_cdc_line_coding, baud=115200
    after setup
    It is now blinking?
    Last edited by defragster; 01-10-2019 at 07:38 AM. Reason: it can work

  22. #647
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,344
    Fresh post follow up - it seems to be working - but I have to push button now?

    Manitou - did you run Set_Arm_Clock on your T4?

    Initial Serial USB not always showing - it is different? I need to Reboot - PORTS are not right again.

    Pic of Ports Menu:
    Attachment 15551

    Rebooted machine - which was seemingly messed up above - no TyCommander updates - just games with power and speed as noted …

    Machine seems fine - good ports menu and T4 programs just fine.
    Last edited by defragster; 01-09-2019 at 03:34 AM.

  23. #648
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,167
    Manitou - did you run Set_Arm_Clock on your T4?
    Tim. Never tried changing the clock speed direct from the sketch only from the startup file, and that was never a problem. Didn't look close at the code for set_arm_clock but I know there are all kinds of warning about changing clocks while running. Wonder if the USB speed got messed up some how which caused the ports to be lost? Just talking out loud.

    In the temp monitor SDK example they change AHB divider but the function has a handshaking function going on, it checks the CDHIPR register which states:
    The CDHIPR register contains read-only bits that indicate that CCM is in the process of updating dividers or muxes that might need handshake with modules
    Page 728. clockspeed.c doesn't wait for the clocks not to be busy so it probably messed all the clocks up. Know I am not saying this right but think you get the idea.

  24. #649
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,167
    @defragster - just went through the sdk example, getting good with the clock stuff, a down and dirty for changing the arm clock would be something like this (It needs a lot of clean up before really ready), it is untested - will do that tomorrow:

    PS: You should recognizer your assert function from ahrs days

    Divider is 1, default - got this from p676 of the ref manual (fig 18-2 clock tree), haven't verified this yet

    WARNING: UNTESTED

    Code:
    #define CCM_TUPLE(reg, shift, mask, busyShift)                                                                     \
        ((((uint32_t)(&((CCM_Type *)0U)->reg)) & 0xFFU) | ((shift) << 8U) | ((((mask) >> (shift)) & 0x1FFFU) << 13U) | \
         ((busyShift) << 26U))
    #define CCM_TUPLE_REG(base, tuple) (*((volatile uint32_t *)(((uint32_t)(base)) + ((tuple)&0xFFU))))
    #define CCM_TUPLE_SHIFT(tuple) (((tuple) >> 8U) & 0x1FU)
    #define CCM_TUPLE_MASK(tuple) ((uint32_t)((((tuple) >> 13U) & 0x1FFFU) << ((((tuple) >> 8U) & 0x1FU))))
    #define CCM_TUPLE_BUSY_SHIFT(tuple) (((tuple) >> 26U) & 0x3FU)
    
    #define CCM_NO_BUSY_WAIT (0x20U)
    
    #define assert_( a ) if (!a) { assert_3(__FILE__, __LINE__,  #a); }
    // handle diagnostic informations given by assertion and abort program execution:
    void assert_3(const char *__file, int __lineno, const char *__sexp) {
      // transmit diagnostic informations through serial link.
      // Serial.println(__func);
      //Serial.println(" ___ ASSERT FAILED ___ FILE, LINE#, Expression ");
      //Serial.println(__file);
      //Serial.println(__lineno, DEC);
      //Serial.println(__sexp);
      //Serial.flush();
      // abort program execution.
      //xxx abort();
      Serial.println(" ___ ASSERT FAILED ___ STOPPING !!!!");
      Serial.printf("ASSERT ERROR \" %s \": file \"%s\" Line \"%d\" function name \"%s\" \n", __sexp, __file, __lineno, __func);
      
      while ( 1 );
    }
    
    
    static inline void CLOCK_SetAHBDiv(uint32_t value)
    {
        uint32_t busyShift;
    
        busyShift = CCM_TUPLE_BUSY_SHIFT(0x1U);
        CCM_TUPLE_REG(IMXRT_CCM, 0x1U) = (CCM_TUPLE_REG(IMXRT_CCM, 0x1U) & (~CCM_TUPLE_MASK(0x1U))) |
                                      (((uint32_t)((value) << CCM_TUPLE_SHIFT(0x1U))) & CCM_TUPLE_MASK(0x1U));
    
        assert(busyShift <= CCM_NO_BUSY_WAIT);
    
        /* Clock switch need Handshake? */
        if (CCM_NO_BUSY_WAIT != busyShift)
        {
            /* Wait until CCM internal handshake finish. */
            while (CCM_CDHIPR & (1U << busyShift))
            {
            }
        }
    }

  25. #650
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,344
    So that's my second Scare where everything came back after Windows reboot. And the IDE's T_port menu entries - were out of sorts as shown.

    Common thread may be … tormenting Windows USB and T_ports?:
    > the first time the 7 seg LED was powering from data/control lines and/or spurious GND wire - may have been putting T4 in shutdown?
    > second time I was cycling power with AMP meter leads after Power Off? - this time power wire to other parts pulled and unplugged LCD to measure only T4 current.

    In this case not sure which happened first - Messed up USB or Odd speed? T_sermon wasn't connecting - but on opening TyComm it could connect and get output.

    Mike: First thing I saw was button required - thought of manitou testing - probably just USB confusion. No warnings in the set_arm_clock() code - though I did have to add extern "C" for compiler to find it.
    I assume on restart all clocks start fresh for 600 MHz run - thought maybe not so that is why I did 15 second reset - odd thing was Amps read in 20's and 30's while it wasn't running right. That part still doesn't make sense with power that low the T4 was not running?

    Cool to see the assert_() usable! I have it in the debug_t3 code … now that Kurt has all Serial#'s working I was thinking I should get back and redo that for T4. Paul has minimal 'dump' on _faults I could start with - but his 'void unused_interrupt_vector(void);' isn't weak …

    There just hacked Core T:\arduino-1.8.8T4_146\hardware\teensy\avr\cores\teensy4\star tup.c:
    // WAS >> // void unused_interrupt_vector(void);
    void unused_interrupt_vector(void) __attribute__ ((weak, alias("unused_interrupt_vectorX")));

    // ...

    // void unused_interrupt_vector(void) __attribute__ ((weak, alias("unused_interrupt_vectorX")));


    void unused_interrupt_vectorX(void)
    Then I went back to the FAULT in Coremark and indeed my local Sketch function gets called.

    It is still Hard Hanging without :: // TODO: polling Serial to complete buffered transmits
    KurtE / Paul - do you have code to keep Serial Polling running so MCU responds to USB to Upload? Maybe this only makes sense or will be known with USB rewrite ...


    Correct operation validated. See README.md for run and reporting rules.
    CoreMark 1.0 : / GCC5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]
    _Tim Was Here_
    T:\tCode\T4\teensy4_coremark\teensy4_coremark.inou nused_interrupt_vector
    _Tim Was Here_

    irq 3
    60001309
    0000104C
    Last edited by defragster; 01-09-2019 at 08:50 AM.

Posting Permissions

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