Forum Rule: Always post complete source code & details to reproduce any issue!
Page 78 of 81 FirstFirst ... 28 68 76 77 78 79 80 ... LastLast
Results 1,926 to 1,950 of 2005

Thread: Teensy 4.0 First Beta Test

  1. #1926
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,776
    Quote Originally Posted by Frank B View Post
    @Paul can you add small pads (large enough to solder thin wires) where the flash-chip signals are accessible (and a way to deselect its chipselect externally)?
    It would open a way to add a PSRAM like this: https://www.electrodragon.com/produc...s6404-iot-ram/
    If you want see DOOM on the T4 we need this
    8 MBytes of RAM for <$1 is amazing - last RAM I saw was 128 KB for multiple $'s

    Frank are you saying you want to be able to use BOTH RAM and SD card? So extra pads and a way to take the SD card offline to use those pins for the RAM access? Or is there something else tied to the CS use in operation?

    DOOM would be cool - and probably faster than the last computers some of us ran it on.

  2. #1927
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,410
    If it is possible to use the flash-signals for the ram it would be cached automatically.. we could just copy the flash to the ram to avoid problems. dunno if the interface supports more chipselects? If yes, even simpler..

    I saw ESP modules using PSRAM.
    Last edited by Frank B; 03-11-2019 at 10:42 AM.

  3. #1928
    Senior Member
    Join Date
    Feb 2013
    Posts
    552
    Quote Originally Posted by PaulStoffregen View Post
    Before messing with the on/off pin, please try commenting out the CPU speed change in startup.c.

    Code:
            set_arm_clock(600000000);
    thanks, Paul. i've tried but it doesn't help it, unfortunately. fwiw, i've tried with three different PSUs (both linear and switching), which either feed a local 5V LDO (800mA) or a RECOM DC/DC converter, which in turn feeds the VIN pin. for now / testing purposes, it's not a biggie, i can bring up the teensy with USB and only then power the boards, it looks though as if people will eventually will run into boot-up issues (my scenario, for example, would be fairly wide-spread in music electronics).

  4. #1929
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    1,859
    Quote Originally Posted by PaulStoffregen View Post
    RT1062 brings GPT2_CAPTURE1 to GPIO_AD_B1_03, which is routed to Arduino 15/A1.
    Ah, thanks. 1060 reference manual Table 9-1 does not show that option, but it is documented in Chapter 10 MUX pad details.

  5. #1930
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,410
    Tim, no,not the SD Interface. The quad-spi for the flash-chip is ideal.

    Edit: ordered a hand full... :-)
    Should work with the audioshield, too, for the older Teensys. but without the cache and quad-spi. (Or, with my old memory board.. 6x8MB have to check the exact package-size..
    Last edited by Frank B; 03-11-2019 at 11:47 AM.

  6. #1931
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,048
    Quote Originally Posted by Frank B View Post
    @Paul can you add small pads (large enough to solder thin wires) where the flash-chip signals are accessible (and a way to deselect its chipselect externally)?
    It would open a way to add a PSRAM like this: https://www.electrodragon.com/produc...s6404-iot-ram/
    If you want see DOOM on the T4 we need this
    100MHz SPI clock, becomes interesting
    On a previous T3.1 system, I did the following,
    on data available from ADC store on extRAM via spi,
    on uSD available get data from extRAM and store on uSD

    NOW:
    with uSD access via SDIO
    and extRAM access vio QSPI

    one could fill-up latest 400GB uSD cards very quickly
    (8 channels 192 kHz 32 bit + 4.608 MByte/s = 22.1GB/hour)

    at the same time 8 MB RAM would give a buffer for 1.3 s

    (OK, after dreaming I will wait for final T4)

  7. #1932
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,410
    I wish I had seen this RAM a bit earlier.

  8. #1933
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    2,647
    FLEXCAN CLOCK HELP
    Hi all me again with FLEXCAN. For the life of me I can not get Flexcan working..... I ported the SDK version over to the T4 and its doing the exact same thing as @tonton81's library is doing, i.e., gets stuck on transmit (doesn't receive either). Doesn't look like there is an signal on pins 0,1 (CAN2). I also tried CAN1 and it doesn't work either so either its a problem with the way I am setting up the clock or pin configs.

    I think I need a sanity check on how I am setting up the Flexcan clock first and then I can play with the pin configurations. So here goes.

    In the SDK example the clock is configured with the following parameters:
    Code:
    /* Select 80M clock divided by USB1 PLL (480 MHz) as master flexcan clock source */
    #define FLEXCAN_CLOCK_SOURCE_SELECT (2U)
    /* Clock divider for master flexcan clock source */
    #define FLEXCAN_CLOCK_SOURCE_DIVIDER (3U)
    /* Get frequency of flexcan clock */
    #define EXAMPLE_CAN_CLK_FREQ ((CLOCK_GetFreq(kCLOCK_Usb1PllClk) / 6) / (FLEXCAN_CLOCK_SOURCE_DIVIDER + 1U))
    The sketch I have configures the clock as follows:
    Code:
      CCM_CSCMR2 = (CCM_CSCMR2 & 0xFFFFFC03) | CCM_CSCMR2_CAN_CLK_SEL(2) |CCM_CSCMR2_CAN_CLK_PODF(3);
    Then I enable the clock:
    Code:
    CCM_CCGR0 |= (0xF << 18);
    I also tried:
    Code:
      CCM_CCGR0 |= CCM_CCGR0_CAN2(CCM_CCGR_ON); 
      CCM_CCGR0 |= CCM_CCGR0_CAN2_SERIAL(CCM_CCGR_ON);
    I think that is all I have to do to enable the Flexcan Clock. Assuming tonton81 and I did it right it should enable the clock.

    For the pin config:
    Code:
        //-------------------------------------//
        //rx configure pin for flexcan
        CORE_PIN0_CONFIG = 0x10;        // alt 0 is can2
        IOMUXC_FLEXCAN2_RX_SELECT_INPUT = 0x01;
      
        //pin1, can2 TX B0_02
        CORE_PIN1_CONFIG = 0x10;
        //uint32_t fastio =  IOMUXC_PAD_SRE | IOMUXC_PAD_DSE(3) | IOMUXC_PAD_SPEED(3);
    
        CORE_PIN0_PADCONFIG = 0x10B0;
        CORE_PIN1_PADCONFIG = 0x10B0;  // 0x1A081, 0x10B0
    Tried a couple different pad configs as well.

    Thanks
    Mike

  9. #1934
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,953
    quad SPI could be interesting for slave mode setup between 2 T4’s (SPI_MST?)

  10. #1935
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    561
    Quote Originally Posted by Frank B View Post
    Thank you for testing!
    The Wavetable-examples need a "PROGMEM" before the const tables - I'e done that for Zelda and "Simple", but hear some clicks (with headphones) - don't know what that is. Never tried that on a T3.
    Can you try the other wavetable examples and add the missing "PROGMEM" to all of them? (and create a pull-request to the repo?)

    PlaySynthMusic works for me without problems.

    Updated the repository.
    Zelda working perfectly for me now - thanks for the patches Frank;
    "Global variables use 25280 bytes (9%) of dynamic memory, leaving 236864 bytes for local variables. Maximum is 262144 bytes."

    Plenty of room left for multiple sound sources in memory - how exciting

  11. #1936
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,469
    Quote Originally Posted by mxxx View Post
    i've tried with three different PSUs (both linear and switching), which either feed a local 5V LDO (800mA) or a RECOM DC/DC converter, which in turn feeds the VIN pin.
    Do you have an oscilloscope? Any chance you could capture the VIN & 3.3V startup waveforms?

    Or can you give me more precise info about the exact power supplies you're using, so I can try to duplicate it here?

  12. #1937
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    561
    SimpleDrum example works fine but only while the serial monitor is open!!?? I must admit I had trouble getting it to run - had to try quite a few times and can't work out why...

    edit: So resetting the board doesn't fix it - opening the serial monitor i only get one line - but resetting the board while the serial monitor is open makes the loop work

  13. #1938
    Senior Member duff's Avatar
    Join Date
    Jan 2013
    Location
    Las Vegas
    Posts
    936
    Quote Originally Posted by PaulStoffregen View Post
    If anyone with the 1052 beta wants to hack their board for PMIC_ON_REQ, you can find a pair of (tiny 402 size) resistors just to the right hand side of the 3.3V regulator.
    Where is the 3.3V regulator located on the board?

  14. #1939
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,469
    Quote Originally Posted by duff View Post
    Where is the 3.3V regulator located on the board?
    Just below and to the right of the USB connector. It's the square chip located above and slightly to the left of Arduino pin 1.

  15. #1940
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    561
    MidiSynthLarge won't compile.

    If I select plain old Midi under Tool > USB it hangs on the serial output usage.
    If i select any of the other options with Midi and Serial (including Midix versions) i get "MidiSynthLarge:120: error: 'usbMIDI' was not declared in this scope".
    So I tried going back to just MIDI and deleting all the Serial references - however as expected - this just brought me back to "usbMidi was not declared in this scope."

    I'll write some simpler code to see if I can get usbmidi to work at all

    Edit: Nope - even the example code here doesn't compile - same error.
    So that's in and out usb midi not working at the moment.

  16. #1941
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    561
    Similiar Problem with PassThroughUSB - setting USB type to Audio doesn't allow the example to compile at this time.

  17. #1942
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    561
    Quote Originally Posted by PaulStoffregen View Post
    Yes, indeed USB is very complicated. The controllers in this new chip are basically the same as the 2nd port on Teensy 3.6 (where we've only supported host mode, never device mode). It's completely different than the main port on all Teensy 3.x boards. The hardware is far more powerful, but also more complex, and that's all on top of the tremendous complexity of USB in general.

    I'm planning to make some changes from the overall USB stack design from Teenxy 3.x, mainly with how memory is allocated. Most of those design choices were made in 2011-2012 for Teensy 3.0 with only 16K RAM. Those choices also revolve around that controller's hardware operating at the USB token level. Now that we have far more RAM, 20X the bandwidth (480 Mbit vs 12 Mbit), and a controller scheme designed around the USB transfer level, I'm planning to do things differently. The main difference will involve the memory allocation. I want to get away from a shared pool of buffers at the device level. The general idea for 4.x is memory allocated by the interface level code.

    So the code for Teensy 3.x isn't a good road map for how I want this to work on Teensy 4.
    that explains it I'll move on to FastLED for now

  18. #1943
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,776
    Quote Originally Posted by Pensive View Post
    that explains it I'll move on to FastLED for now
    As you found - Serial goes blocking when used if SerMon is not online - also Serial is T4 write only with NOP's for most of the rest of the func()'s - but a bit faster than T_3.x's. Have to use a Serial# port if bidirectional I/O is needed. Suppose you found the Serial4 Tx pin presents debug info? New USB stack is in Paul's queue.

  19. #1944
    Senior Member Pensive's Avatar
    Join Date
    Aug 2014
    Location
    Basingstoke, UK
    Posts
    561
    FastLED won't accept any kind of data pin value. It looks like there needs to be some kind of pin mapping added for this particular board. I'm using the DemoReel100 example.

    I'm keeping it simple with a 7 LED neopixel jewel running at maximum 5% on the 3.3v output. I'm not sure if that's going to do some electrical mischief at this stage but I doubt it given the low brightness setting - I'm also not sure if there are any 5v tolerant pins but i doubt it very much - I;ve assume dnot and dont want to complicate things with a converter if I can avoid it. I'm using a 220Ohm resistor on the data pin. I tried multiple data pins - they all came back with the same error.

    Think I'll drop down to one neopixel tomorrow, to be safe. Was hoping for some ridiculously fast fastled action but maybe next time


    Code:
    In file included from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:0:
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:573:2: warning: #warning "No pin/port mappings found, pin access will be slightly slower. See fastpin.h for info." [-Wcpp]
    
     #warning "No pin/port mappings found, pin access will be slightly slower. See fastpin.h for info."
    
      ^
    
    In file included from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:0:
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:17:21: note: #pragma message: FastLED version 3.001.008
    
     #    pragma message "FastLED version 3.001.008"
    
                         ^
    
    In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:68:0,
    
                     from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/fastspi.h:110:23: note: #pragma message: No hardware SPI pins defined.  All SPI access will default to bitbanged output
    
     #      pragma message "No hardware SPI pins defined.  All SPI access will default to bitbanged output"
    
                           ^
    
    In file included from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:0:
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h: In static member function 'static CLEDController& CFastLED::addLeds(CRGB*, int, int)':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:238:62: warning: large integer implicitly truncated to unsigned type [-Woverflow]
    
        case WS2801: { static WS2801Controller<DATA_PIN, CLOCK_PIN> c; return addLeds(&c, data, nLedsOrOffset, nLedsIfOffset); }
    
                                                                  ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h: In static member function 'static CLEDController& CFastLED::addLeds(CRGB*, int, int)':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:251:73: warning: large integer implicitly truncated to unsigned type [-Woverflow]
    
        case WS2801: { static WS2801Controller<DATA_PIN, CLOCK_PIN, RGB_ORDER> c; return addLeds(&c, data, nLedsOrOffset, nLedsIfOffset); }
    
                                                                             ^
    
    In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:51:0,
    
                     from C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:1:
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/fastpin.h: In instantiation of 'class FastPin<1u>':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/platforms/avr/clockless_trinket.h:96:49:   required from 'class ClocklessController<1u, 99, 248, 149, (EOrder)66u, 0, false, 10>'
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/chipsets.h:468:7:   required from 'class WS2812Controller800Khz<1u, (EOrder)66u>'
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:104:52:   required from 'class WS2812<1u, (EOrder)66u>'
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/FastLED.h:298:39:   required from 'static CLEDController& CFastLED::addLeds(CRGB*, int, int) [with CHIPSET = WS2812; unsigned char DATA_PIN = 1u; EOrder RGB_ORDER = (EOrder)66u]'
    
    C:\Users\User\AppData\Local\Temp\arduino_modified_sketch_274248\DemoReel100.ino:32:64:   required from here
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\FastLED/fastpin.h:207:2: error: static assertion failed: Invalid pin specified
    
      static_assert(validpin(), "Invalid pin specified");
    
      ^
    
    Error compiling for board Teensy 4-Beta1.

    SO, I tried adafruit neopixel library "strandtest" instead - also not compiling unfortunately.


    Code:
    In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.c:34:0:
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.h:686:28: error: 'ENDPOINT_TRANSMIT_ONLY' undeclared here (not in a function)
    
       #define ENDPOINT1_CONFIG ENDPOINT_TRANSMIT_ONLY
    
                                ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.c:1559:2: note: in expansion of macro 'ENDPOINT1_CONFIG'
    
      ENDPOINT1_CONFIG,
    
      ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.h:687:28: error: 'ENDPOINT_RECEIVE_ONLY' undeclared here (not in a function)
    
       #define ENDPOINT2_CONFIG ENDPOINT_RECEIVE_ONLY
    
                                ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb_desc.c:1564:2: note: in expansion of macro 'ENDPOINT2_CONFIG'
    
      ENDPOINT2_CONFIG,
    
      ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c: In function 'endpoint0_setup':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:311:23: error: 'CDC_ACM_ENDPOINT' undeclared (first use in this function)
    
       endpoint_queue_head[CDC_ACM_ENDPOINT*2+1].config = (CDC_ACM_ENDPOINT << 16);
    
                           ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:311:23: note: each undeclared identifier is reported only once for each function it appears in
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:312:23: error: 'CDC_RX_ENDPOINT' undeclared (first use in this function)
    
       endpoint_queue_head[CDC_RX_ENDPOINT*2+0].config = (CDC_RX_SIZE << 16) | (1 << 29);
    
                           ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:312:54: error: 'CDC_RX_SIZE' undeclared (first use in this function)
    
       endpoint_queue_head[CDC_RX_ENDPOINT*2+0].config = (CDC_RX_SIZE << 16) | (1 << 29);
    
                                                          ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:313:23: error: 'CDC_TX_ENDPOINT' undeclared (first use in this function)
    
       endpoint_queue_head[CDC_TX_ENDPOINT*2+1].config = (CDC_TX_SIZE << 16) | (1 << 29);
    
                           ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:313:54: error: 'CDC_TX_SIZE' undeclared (first use in this function)
    
       endpoint_queue_head[CDC_TX_ENDPOINT*2+1].config = (CDC_TX_SIZE << 16) | (1 << 29);
    
                                                          ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:338:3: error: 'usb_cdc_line_rtsdtr_millis' undeclared (first use in this function)
    
       usb_cdc_line_rtsdtr_millis = systick_millis_count;
    
       ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:339:3: error: 'usb_cdc_line_rtsdtr' undeclared (first use in this function)
    
       usb_cdc_line_rtsdtr = setup.wValue;
    
       ^
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c: In function 'endpoint0_complete':
    
    C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\usb.c:433:10: warning: variable 'setup' set but not used [-Wunused-but-set-variable]
    
      setup_t setup;
    
              ^
    
    Error compiling for board Teensy 4-Beta1.

  20. #1945
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,469
    Quote Originally Posted by PaulStoffregen View Post
    Or can you give me more precise info about the exact power supplies you're using, so I can try to duplicate it here?
    I'm building a DC-DC switcher board right now, using a LM2671-5V chip, which has a configurable soft-start feature. I put a 22 nF capacitor on the soft start pin. Hopefully that will be enough?

  21. #1946
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,918
    Quote Originally Posted by defragster View Post
    As you found - Serial goes blocking when used if SerMon is not online - also Serial is T4 write only with NOP's for most of the rest of the func()'s - but a bit faster than T_3.x's. Have to use a Serial# port if bidirectional I/O is needed. Suppose you found the Serial4 Tx pin presents debug info? New USB stack is in Paul's queue.
    Yeah, I had just noticed that. I was hoping it might be a known bug. I must admit that I really like the ability in T3 to do Serial print's, not worrying whether the USB was connected or not.

  22. #1947
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    7,776
    Quote Originally Posted by MichaelMeissner View Post
    Yeah, I had just noticed that. I was hoping it might be a known bug. I must admit that I really like the ability in T3 to do Serial print's, not worrying whether the USB was connected or not.
    Seems it worked non-Blocking in Dec - then went blocking after next Beta …

    Quote Originally Posted by defragster View Post
    ...
    Yes Kurt - Serial writes Block with no SerMon - that was my request looking for confirmation in post #381

    I noticed that Last Year Dec 31st in post #182 and it got logged … That came with Beta #4 in post #180 - it worked non-blocking in the prior beta - at the same time startup entry and Serial online came 100 [or more ] ms later than prior beta 3.

    No doubt it will get fixed - but like the dead cycle counter it can mess with testing - I was doing the 1.5 MB SPEW testing and then killing SerMon to save the USB overload - and was testing for 'if ( Serial )' that came online in Beta 3 - then it went blocking … thought it was my machine as nobody else noticed.
    <edit> From that post going back a couple of days to 2nd Jan Paul noted my post … waiting to follow up on my end when USB stack update is delivered.

    From :: 12-31-2018, 10:55 AM post #182 after Beta 4 release
    Quote Originally Posted by defragster View Post
    Downloaded and installed: Good work.

    CycleCounter Problem solved in the sketches I ran - CycleCounter was active coming into setup()!

    <edit>: And the USB debug control of LED_BUILTIN is out so the LED BLINKS right!

    I see that :: while ( !Serial && millis() < 1000 ); now leaves the loop for Serial==TRUE! at millis=543 ! Though BLINK stops when SerMon Closed until opened
    ...
    Last edited by defragster; 03-12-2019 at 10:01 AM.

  23. #1948
    Senior Member
    Join Date
    Feb 2013
    Posts
    552
    Quote Originally Posted by PaulStoffregen View Post
    Do you have an oscilloscope? Any chance you could capture the VIN & 3.3V startup waveforms?

    Or can you give me more precise info about the exact power supplies you're using, so I can try to duplicate it here?
    sure, this is one i had access to this morning. yellow is VIN, blue is 3v3:

    Click image for larger version. 

Name:	47303865592_13e4b17e4a_o.jpg 
Views:	18 
Size:	71.3 KB 
ID:	16122

    in this case, the 5V regulator is a LM1117, with 10uF at the input + output (this is the thing in question). (the LM1117 here is fed from a -/+12V supply (2.4A), but details here are beyond control of the designer, so to speak, there's a huge variety of +/- 12V PSUs people will use for powering synths).

    the exact same board works for teensy 3.2 (without further ado) and teensy 3.6 (needs a MIC803).
    Last edited by mxxx; 03-12-2019 at 06:58 AM. Reason: added link to schematic

  24. #1949
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,410
    Paul, any chance for the PSRAM?

  25. #1950
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,469
    I'm investigating the power startup issue now.

    I can reproduce the problem here, at least in some cases. So far, I can only get it to happen when the 12V power starts up very slowly. Even with a 5V circuit having a long soft-start time, I can't make the problem happen if the 12V supply is already on and I connect the 12V power to the 5V supply by plugging in a connector. But if I turn a very slow starting 12V supply on/off, it's startup is so slow it affects the 5V startup, and that is affecting everything else enough to cause the startup problem.

    If you could do another test, any chance you use that 3rd scope channel to monitor the 12V power too? Can you test whether turning the 12V supply on/off versus connecting an already-on 12V supply make a difference?

    I can also say the PMIC_ON_REQ change makes a huge difference. So far I have not been able to get the problem to ever happen on the board with that change. I'm going to add more wires to both boards, so I can watch the startup of both 1.1V power, and maybe the 2.5V PLL power too. I have a couple theories about what might be happening here, but more work needed to really get to the bottom of this.

    If you can do another test, to check whether the 12V supply's startup is a factor (difference between starting up the 12V supply while connected, versus pre-starting the 12V supply and then plugging it into the 5V regulator) that info would really help me to know whether I should focus more testing effort on the 5V stuff. I do have some LM1117 chips here, but they're all 3.3V, not 5V. I can get the 5V one in a few days, but maybe it's really that 12V 2.4A supply I need?

Posting Permissions

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