Forum Rule: Always post complete source code & details to reproduce any issue!
Page 126 of 154 FirstFirst ... 26 76 116 124 125 126 127 128 136 ... LastLast
Results 3,126 to 3,150 of 3832

Thread: Teensy 4.0 First Beta Test

  1. #3126
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,014
    Quote Originally Posted by PaulStoffregen View Post
    I've committed a fix for the eeprom problems after a cold boot.
    Thanks! looks good.

  2. #3127
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,837
    Just to confirm for reference note - the latest Ribbon T4B2m on breakout [ 2nd tested white wire B2m ]:
    --> I cannot cause a brown out fail to start.
    > With VBat powered by a cr2032 when unpowered by USB or any UARTS WILL Honor the power button:
    >> take a 5 second POWER press as an OFF when again powered if unpowered when ON
    >> take a short POWER press as an ON when again powered if unpowered when OFF
    > with single UART Rx/Tx on Serial4 to T_3.1 - and 0V VBat - the POWER button is ignored when unpowered - no visible Green LED glow.
    > with UART Rx/Tx on Serial4 to T_3.1, and Serial2 to T_3.5 - and 0V VBat - the POWER button is Honored when unpowered - visible Green LED glow.

    And the EEPROM GetPut posted works well for uint32_t in [0], and then groups of expanded Float+MyObject to end of EEPROM
    > when Packed to odd bytes [19], or unpacked with 24 bytes
    -- and when started on any of 4 byte boundary offsets
    -- works across Multiple cycles through EEPROM
    >> It works on USB cable pull, or processor restart/Reset
    >> With EEPROM fix - the spurious error with shifted data is gone - probably from unseen failure to write the starting index location as @manitou discovered

    Prior note tested CAN2 on CANFD port.

    Also tested USB_Host SD card and HDD and USB FLASH to work.

  3. #3128
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    Quote Originally Posted by PaulStoffregen View Post
    I've committed a fix for the eeprom problems after a cold boot.
    I'll second what everyone else has said. That looks like it fixed it. Ran 2 tests:

    (1) write from serial monitor a series of numbers or chars to the EEPROM, verified it wrote those values to the EEPROM. Un/Re-plugged the USB cable in wrote a different set of chars to the eeprom and yeah verily it wrote it fine to the EEPROM.

    (2) Hooked up the Prop Shield and ran CalibrateSensors with MotionCal App. After cal did the send to CAL and got the check that it sent. From calibrate sensor sketch (moded it to read the cal data and send to Serial1) I verified that it wrote the values:
    Code:
    Calibration Data
    Magnetic (Hard Iron) Offsets
      17.22 uT
      -8.51 uT
      64.54 uT
    
    Magnetic Soft Iron Mapping
      0.9758  -0.0193  -0.0073
      -0.0193  0.9986  -0.0025
      -0.0073  -0.0025  1.0267
    
    Expected Magnetic Field Strength
      40.01 uT
    Next ran the PrintCal sketch and got pretty much the same numbers as another verification:
    Code:
      
      Calibration Data
    
    Magnetic (Hard Iron) Offsets
       17.22 uT
      -8.51 uT
       64.55 uT
    
    Magnetic Soft Iron Mapping
       0.9756  -0.0192  -0.0077
      -0.0192   0.9985  -0.0026
      -0.0077  -0.0026   1.0270
    
    Expected Magnetic Field Strength
       40.01 uT
    As reference this is a screenshot from motion cal:
    Name:  Capture.JPG
Views: 261
Size:  42.0 KB

  4. #3129
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,913
    Quote Originally Posted by PaulStoffregen View Post
    I've committed a fix for the eeprom problems after a cold boot.

    https://github.com/PaulStoffregen/co...a2d634ee29c450

    The bootloader does indeed fully initialize the FlexSPI LUT memory. Even if a LUT contains a stop instruction, turns out the hardware gets upset if any of LUT's the 8 instructions are invalid, even after a stop. I didn't realize this until now (kind of assumed it didn't read anything after the stop instruction - NXP's manual doesn't really say either way but kind of implied it reads the LUT's instructions in order), so the code was depending on the bootloader leaving the LUTs in a "clean" state. These extra initialization writes should fully solve the problem where the LUT table has unknown garbage after a cold boot.
    I am glad that fixed it! I was wondering, which is why in the last test run, I printed out LUT60-63 and that was going to be my next thing to try but got hit by another diversion...

    What made me wonder about this was section 26.7.7 (page 1784 of new rev of manual) The note under the table:
    If the instruction number needed is less than 8 for a flash
    transaction, STOP instruction should be programmed for the
    unneeded instructions (instruction code 8'h00).
    I also confirmed the fix I ran the last test again and now after re-powering the T4...
    Code:
    CCM_CCGR6: fcff3fc3 CCM_CCGR7: ffffffff
    byte 0 98
    FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:77f2db4a
        LUT60:64bf3240 LUT61:d292adcc LUT62:16f89264 LUT63:865f453b
    FLEXSPI MCR0:ffff8010 MCR1:7736ffff MCR2:200001f7 AHBCR:78 INTEN:0 INTR:40 RFDR0:44
        LUT60:24010405 LUT61:0 LUT62:0 LUT63:0
    input 99 byte 0 99
    EEPROM length: 1080
    Contents:
    0:63 1:1 2:2 3:3 4:4 5:5 6:6 7:7 8:8 9:9 a:a b:b c:c d:d e:e f:f 
    10:10 11:11 12:12 13:13 14:14 15:15 16:16 17:17 18:18 19:19 1a:1a 1b:1b 1c:1c 1d:1d 1e:1e 1f:1f 
    20:20 21:21 22:22 23:23 24:24 25:25 26:26 27:27 28:28 29:29 2a:2a 2b:2b 2c:2c 2d:2d 2e:2e 2f:2f 
    30:30 31:31 32:32 33:33 34:34 35:35 36:36 37:37 38:38 39:39 3a:3a 3b:3b 3c:3c 3d:3d 3e:3e 3f:3f 
    40:40 41:41 42:42 43:43 44:44 45:45 46:46 47:47 48:48 49:49 4a:4a 4b:4b 4c:4c 4d:4d 4e:4e 4f:4f 
    50:50 51:51 52:52 53:53 54:54 55:55 56:56 57:57 58:58 59:59 5a:5a 5b:5b 5c:5c 5d:5d 5e:5e 5f:5f 
    60:60 61:61 62:62 63:63 64:64 65:65 66:66 67:67 68:68 69:69 6a:6a 6b:6b 6c:6c 6d:6d 6e:6e 6f:6f 
    70:70 71:71 72:72 73:73 74:74 75:75 76:76 77:77 78:78 79:79 7a:7a 7b:7b 7c:7c 7d:7d 7e:7e 7f:7f 
    80:80 81:81 82:82 83:83 84:84 85:85 86:86 87:87 88:88 89:89 8a:8a 8b:8b 8c:8c 8d:8d 8e:8e 8f:8f 
    90:90 91:91 92:92 93:93 94:94 95:95 96:96 97:97 98:98 99:99 9a:9a 9b:9b 9c:9c 9d:9d 9e:9e 9f:9f 
    a0:a0 a1:a1 a2:a2 a3:a3 a4:a4 a5:a5 a6:a6 a7:a7 a8:a8 a9:a9 aa:aa ab:ab ac:ac ad:ad ae:ae af:af 
    b0:b0 b1:b1 b2:b2 b3:b3 b4:b4 b5:b5 b6:b6 b7:b7 b8:b8 b9:b9 ba:ba bb:bb bc:bc bd:bd be:be bf:bf 
    c0:c0 c1:c1 c2:c2 c3:c3 c4:c4 c5:c5 c6:c6 c7:c7 c8:c8 c9:c9 ca:ca cb:cb cc:cc cd:cd ce:ce cf:cf 
    d0:d0 d1:d1 d2:d2 d3:d3 d4:d4 d5:d5 d6:d6 d7:d7 d8:d8 d9:d9 da:da db:db dc:dc dd:dd de:de df:df 
    e0:e0 e1:e1 e2:e2 e3:e3 e4:e4 e5:e5 e6:e6 e7:e7 e8:e8 e9:e9 ea:ea eb:eb ec:ec ed:ed ee:ee ef:ef 
    f0:f0 f1:f1 f2:f2 f3:f3 f4:f4 f5:f5 f6:f6 f7:f7 f8:f8 f9:f9 fa:fa fb:fb fc:fc fd:fd fe:fe ff:ff 
    
    Raw Data
    EEprom Page:0 addresses(601f0000 - 601f1000): first free: 601f008a
      000(00)=08  001(01)=09  002(02)=0a  003(03)=0b  060(04)=44  061(05)=45  062(06)=46  063(07)=47  120(08)=80  121(09)=81  122(0a)=82  123(0b)=83  180(0c)=bc  181(0d)=bd  182(0e)=be  183(0f)=bf
      240(10)=f8  241(11)=f9  242(12)=fa  243(13)=fa *300(14)=b3 *301(15)=b3 *302(16)=b3 *303(17)=b3  243(13)=fb  000(00)=78  000(00)=0d  000(00)=79  000(00)=0d  000(00)=00 *001(01)=01 *002(02)=02
     *003(03)=03 *060(04)=3c *061(05)=3d *062(06)=3e *063(07)=3f *120(08)=78 *121(09)=79 *122(0a)=7a *123(0b)=7b *180(0c)=b4 *181(0d)=b5 *182(0e)=b6 *183(0f)=b7 *240(10)=f0 *241(11)=f1 *242(12)=f2
     *243(13)=f3  000(00)=78  000(00)=0d  000(00)=78  000(00)=0d  000(00)=78  000(00)=59  000(00)=31  000(00)=32  000(00)=35  000(00)=31  000(00)=32  000(00)=37  000(00)=38  000(00)=31  000(00)=61
      000(00)=63  000(00)=31  000(00)=61  000(00)=62 *000(00)=63
    This also verified how the data was output into the first sector...

  5. #3130
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,913
    EEPROM side note - probably not worth investigating...

    With eeprom_read_byte - it always scans the complete used part of the sector to find the last time a value was set:
    Code:
    uint8_t eeprom_read_byte(const uint8_t *addr_ptr)
    {
    	uint32_t addr = (uint32_t)addr_ptr;
    	uint32_t sector, offset;
    	const uint16_t *p, *end;
    	uint8_t data=0xFF;
    
    	if (addr > E2END) return 0xFF;
    	if (!initialized) eeprom_initialize();
    	sector = (addr >> 2) % FLASH_SECTORS;
    	offset = (addr & 3) | (((addr >> 2) / FLASH_SECTORS) << 2);
    	//printf("ee_rd, addr=%u, sector=%u, offset=%u, len=%u\n",
    		//addr, sector, offset, sector_index[sector]);
    	p = (uint16_t *)(FLASH_BASEADDR + sector * 4096);
    	end = p + sector_index[sector];
    	while (p < end) {
    		uint32_t val = *p++;
    		if ((val & 255) == offset) data = val >> 8;
    	}
    	return data;
    }
    I know when I was playing around with the OpenCM9.04 boards eeprom code, I got a slight speed up when I started from the end and scanned back toward the start of the sector as I could return as soon as I found any value for the index...

    Something like:

    Code:
    uint8_t eeprom_read_byte(const uint8_t *addr_ptr)
    {
    	uint32_t addr = (uint32_t)addr_ptr;
    	uint32_t sector, offset;
    	const uint16_t *p, *begin;
    
    	if (addr > E2END) return 0xFF;
    	if (!initialized) eeprom_initialize();
    	sector = (addr >> 2) % FLASH_SECTORS;
    	offset = (addr & 3) | (((addr >> 2) / FLASH_SECTORS) << 2);
    	//printf("ee_rd, addr=%u, sector=%u, offset=%u, len=%u\n",
    		//addr, sector, offset, sector_index[sector]);
    	begin= (uint16_t *)(FLASH_BASEADDR + sector * 4096);
    	p = begin + sector_index[sector] -1;
    	while (p >= begin) {
    		uint32_t val = *p--;
    		if ((val & 255) == offset) return val >> 8;
    	}
    	return 0xff;
    }
    Note: made changes here on fly did not try in code, need to verify some edge conditions like page full, page empty...

  6. #3131
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    Just got my shiny new Breakout board and new T4 (now calling it T4B2B - last B is for Battery Holder) .

    Ran ListFiles from SD library with out issue. Only thing is can't specify CS as pin 36 had to specify it as BUILTIN_SDCARD. Also you have to specify:
    Code:
      SPI.setMOSI(35);
      SPI.setSCK(37);
      SPI.setSCK(34);
    to get it to work.

    Also ran the uSDFS code that we used to identify partitions and it worked and identified the single partition and FAT32 format. Believe @defragster already ran some other tests with uSDFS library.

    EDIT1:
    On the exFAT partition with the default settings for buffersize I am seeing:
    Code:
    Change drive
    A_00001.dat
    stat FR_OK 0
     opened FR_OK 0
    ................................................................
    .................................... (3010996 - 10.882777 MB/s)
     (open: 9016 us; close: 8979 us; write: min,max: 2977 3979 us)
    Last edited by mjs513; 06-04-2019 at 05:11 PM.

  7. #3132
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,837
    Quote Originally Posted by mjs513 View Post
    Just got my shiny new Breakout board and new T4 (now calling it T4B2B - last B is for Battery Holder) .
    ...
    Battery holder is on the breakout though … I was calling it Ribbon due to the SD pin spacing change ...

    I wondered about a new indicator - but so far the T4 on the newest board - with the Ribbon still has White Wire edit and only the SD ribbon pin spacing was the noted intended change so T4B2m? {or T4B2r if it shows any diffs}

    Anyhow it is a really nice looking package - and indeed PCB washed nice and clean on nice base!

    Anyone lurking here on the Beta list if you have time to practice some 'Normal Use' - or following the Msg#4 and #6 status/issues list - it would be a good time to send an email if not too late and 'Get Some' - and have a chance to see it early and maybe come across something otherwise unfound that would be a bother later.

  8. #3133
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    Quote Originally Posted by defragster View Post
    Battery holder is on the breakout though … I was calling it Ribbon due to the SD pin spacing change ...

    I wondered about a new indicator - but so far the T4 on the newest board - with the Ribbon still has White Wire edit and only the SD ribbon pin spacing was the noted intended change so T4B2m? {or T4B2r if it shows any diffs}

    Anyhow it is a really nice looking package - and indeed PCB washed nice and clean on nice base!

    Anyone lurking here on the Beta list if you have time to practice some 'Normal Use' - or following the Msg#4 and #6 status/issues list - it would be a good time to send an email if not too late and 'Get Some' - and have a chance to see it early and maybe come across something otherwise unfound that would be a bother later.
    In that case I will call it T4B2R = for ribbon Hate to just use wire.

    I actually meant to add to my post that the quality of workmanship and attention to details on the products that PJRC puts out, example the breakout boards, not to mention the Teensies never ceases to amaze me .

  9. #3134
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,837
    Quote Originally Posted by mjs513 View Post
    In that case I will call it T4B2R = for ribbon Hate to just use wire.
    Yeah - there are two versions with wire - but the Ribbon is the first with added bottom silkscreen of the Model #

    I actually meant to add to my post that the quality of workmanship and attention to details on the products that PJRC puts out, example the breakout boards, not to mention the Teensies never ceases to amaze me .
    Quality is impressive - From Teensy itself to the multiple breakout designs and assembly allowing for using the various functional parts. Makes it clear that a lot of thought/work/planning/mastery goes into each Teensy. And amazing that they cost near/under an UNO/etc for so much more. Not to mention the reliable 'magic sauce' bootloader MCU is included in that - offering good design protect of that effort and long term usability with ease.

  10. #3135
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    SD Library:

    Was running through the examples from the SD library:
    Cardinfo.ino - works no problem
    listfiles - woks no problem
    readwrite.ino - not working:
    Code:
    Initializing SD card...initialization done.
    Stops - nothing write
    :
    Datalogger.ino - not working:
    Code:
    Initializing SD card...card initialized.
    stops at this point

    UPDATE:
    1. Ran DataLogger on the T4B2M (wire on bottom) using the Builtin_sdcard and got the same results as the T4B2R.
    2. Ran DataLogger on both versions of the T4 except using the SD card on the audio shield and in both cases the sketch ran and wrote files to the SD Card.
    Last edited by mjs513; 06-04-2019 at 06:21 PM.

  11. #3136
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    SDFAT Library

    Reran the SDFAT library modifications i made back in post #2685 but with a Lexar633x 128GB card - reformatted with the formatting sketch to FAT32 in SDFat Library and ran the sdinfo sketch - this time at 50Mhz:

    Code:
    SdFat version: 1.0.5
    
    Assuming the SD is the only SPI device.
    Edit DISABLE_CHIP_SELECT to disable another device.
    
    Assuming the SD chip select pin is: 10
    Edit SD_CHIP_SELECT to change the SD chip select pin.
    
    type any character to start
    
    init time: 2 ms
    
    Card type: SDXC
    
    Manufacturer ID: 0X95
    OEM ID: SU
    Product:      
    Version: 0.2
    Serial number: 0X520AB128
    Manufacturing date: 3/2015
    
    cardSize: 128042.66 MB (MB = 1,000,000 bytes)
    flashEraseSize: 128 blocks
    eraseSingleBlock: true
    OCR: 0XC0FF8000
    
    SD Partition Table
    part,boot,type,start,length
    1,0X0,0XC,8192,250075136
    2,0X0,0X0,0,0
    3,0X0,0X0,0,0
    4,0X0,0X0,0,0
    
    Volume is FAT32
    blocksPerCluster: 128
    clusterCount: 1953456
    freeClusters: 1953455
    freeSpace: 128021.63 MB (MB = 1,000,000 bytes)
    fatStartBlock: 10436
    fatCount: 2
    blocksPerFat: 15262
    rootDirStart: 2
    dataStartBlock: 40960
    
    type any character to start
    Still works with the SD Card Reader on the Audio Shield.

  12. #3137
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,176
    Quote Originally Posted by defragster View Post
    Anyone lurking here on the Beta list if you have time to practice some 'Normal Use' - or following the Msg#4 and #6 status/issues list - it would be a good time to send an email if not too late and 'Get Some' - and have a chance to see it early and maybe come across something otherwise unfound that would be a bother later.
    Indeed, at this moment I have 5 more beta+breakout boards ready to go, and parts to build 10 more. After those 15 are claimed, the beta will be officially closed. Everyone else who didn't get beta hardware will automatically get a production board (without the fancy breakout hardware) when we release (likely mid-July time frame).

    I'm going to send an email reminder soon to everyone on the beta testers list who hasn't requested hardware yet. If you're following this thread and reading this message and have time to do any beta testing, now's the moment to claim one of those last 15 beta boards.

    The current betas with the white mod wire are electrically identical to the final PCB, where that extra wire was added in layer #4. The production PCB are being fabricated now, so I can say with absolute confidence we will not have any more hardware changes. It's all software-only testing from here.

  13. #3138
    Senior Member
    Join Date
    Oct 2015
    Location
    Roma (IT, EU)
    Posts
    193
    Quote Originally Posted by PaulStoffregen View Post
    Indeed, at this moment I have 5 more beta+breakout boards ready to go, and parts to build 10 more. After those 15 are claimed, the beta will be officially closed
    Wow, I totally missed that I was on the Beta list!!!! Missed that message entirely (and I am following the thread quite closely)!!
    First thing: thanks a lot, it's an honor! I really mean it.

    Unfortunately I've no spare time for at least 3 more weeks (deadline for a Teensy-based project + a trip), so, while I would love to get a beta T4 board, I could not contribute much up to, say, end of June.
    I could run some tests I have in mind on the T4beta after that, if you think my contribution would still be of some use...?
    But I don't want to hijack a beta board if someone can put it to better use.

    Thanks again for putting me on the list!

  14. #3139
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    SDFat vs SDFat-Beta

    Just discovered that Bill Greiman has updated his SDFat library to SDFat -Beta. It runs out of the box without any modifications for the T4. It also supports FAT16/FAT32 and exFAT SD cards. I have been testing it on the T4B2W version. Just can't figure out how to get it to read the builtin_sdcard (one on board). Supposedly all you have to do is something like this:
    Code:
    #define SD1_CONFIG SdSpiConfig(36, DEDICATED_SPI, SD_SCK_MHZ(18), &SPI1)
    .

  15. #3140
    Junior Member
    Join Date
    Jun 2019
    Posts
    4
    Quote Originally Posted by PaulStoffregen View Post
    The production PCB are being fabricated now, so I can say with absolute confidence we will not have any more hardware changes. It's all software-only testing from here.
    Hi Paul, is it the same form factor as the Teensy 3.2? Are there any photos or images? I just went through the last 30 pages of the thread but couldn't see any

    Steve

  16. #3141
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,913
    Quote Originally Posted by Monobass View Post
    Hi Paul, is it the same form factor as the Teensy 3.2? Are there any photos or images? I just went through the last 30 pages of the thread but couldn't see any

    Steve
    You should look at the first page, to get a summary of information. Also note in the first posting of this thread:
    During this beta, I'd like to ask everyone to follow a few simple rules.

    No photos!
    Keep all conversations & info on this forum thread
    (1052 only) Don't mess with the OTP fuses... On the 1062 boards, do mess with the fuses.

  17. #3142
    Junior Member
    Join Date
    Jun 2019
    Posts
    4
    Yes I read the post from December but wondered if Paul posted anything more recently (126 page forum threads aren't the easiest to navigate).
    To be honest all I want to know right now is the size of the board in mm to see if I can upgrade my 3.2 products to use it without too much bother.

  18. #3143
    Member ETMoody3's Avatar
    Join Date
    Mar 2014
    Location
    New Ulm, Mn
    Posts
    37
    I would volunteer that it's fair to call it "Pin Compatible" with 3.2 (with a few differences)

  19. #3144
    Junior Member
    Join Date
    Jun 2019
    Posts
    4
    Quote Originally Posted by ETMoody3 View Post
    I would volunteer that it's fair to call it "Pin Compatible" with 3.2 (with a few differences)
    perfect, thanks

  20. #3145
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,176
    Quote Originally Posted by Monobass View Post
    Are there any photos or images?
    No, and there won't be any photos until the official release. That's the main rule we ask of everyone who's beta testing. We share lots of tech info here, like the pinouts in msg #2, but not photos.

  21. #3146
    Junior Member
    Join Date
    Jun 2019
    Posts
    4
    Quote Originally Posted by PaulStoffregen View Post
    No, and there won't be any photos until the official release. That's the main rule we ask of everyone who's beta testing. We share lots of tech info here, like the pinouts in msg #2, but not photos.
    yep understood, fingers crossed its no wider than 19mm

  22. #3147
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,837
    Quote Originally Posted by Monobass View Post
    yep understood, fingers crossed its no wider than 19mm
    It is the same 7 pins wide across the short end and 14 pins down the long edges and pin spacing is still 0.1". Looks like a T_3.1 overall - with the legs gone from the same size MCU body with some shifting in components ...

  23. #3148
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,913
    There is actually most of the information about what will be the new board contained within this thread:

    Examples: https://forum.pjrc.com/threads/54711...l=1#post200758
    Where Paul states:
    VIN at x=50, y=650

    The plan is for T4 to match the form factor T3.2, at least for overall size and the 28 outside pins.
    Also information about the location of the main surface mount pins

    Posting: https://forum.pjrc.com/threads/54711...l=1#post200666
    Talks about the locations of the surface mount pins under the new T4:

    Code:
    Pin 24: x=1182, y=550
    Pin 25, x=1018, y=550
    Pin 26: x=1182, y=450
    Pin 27, x=1018, y=450
    Pin 28: x=1182, y=350
    Pin 29, x=1018, y=350
    Pin 30: x=1182, y=250
    Pin 31, x=1018, y=250
    Pin 32: x=1182, y=150
    Pin 33, x=1018, y=150
    USB2 D+, x=72, y=305
    USB2 D+, x=72, y=395
    Note I did not include the SD Card pin locations here as they changed:

    As I noted in another posting, that Pins 24-33 are the locations for pogo like pins... If you are going to use pogo pins. If you are going to use the surface mount solder pins like T3.x
    I believe: The x Positions would probably be 1018 -> 1050 and the 1182 -> 1150 I think? (Posting 1981)

    Later the SD Card pads changed to allow a HFW8R-1STE1LF (or similar FFC connector): https://forum.pjrc.com/threads/54711...l=1#post206543
    Code:
    SD DAT1, x=361.22, y=487.80
    SD DAT0, x=361.22, y=448.43
    SD GND, x=361.22, y=409.06
    SD CLK, x=361.22, y=369.69
    SD 3.3V, x=361.22, y=330.32
    SD CMD, x=361.22, y=290.95
    SD DAT3, x=361.22, y=251.58
    SD DAT2, x=361.22, y=212.21
    While not stated here in these messages: From Posting #3 You have the
    additional 5 pins at the far end: ON/OFF, Program GND 3.3v and VBAT

    Where ON/OFF is near pin 13 and VBAT near pin 12...

  24. #3149
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,224
    Quote Originally Posted by mjs513 View Post
    SDFat vs SDFat-Beta

    Just discovered that Bill Greiman has updated his SDFat library to SDFat -Beta. It runs out of the box without any modifications for the T4. It also supports FAT16/FAT32 and exFAT SD cards. I have been testing it on the T4B2W version. Just can't figure out how to get it to read the builtin_sdcard (one on board). Supposedly all you have to do is something like this:
    Code:
    #define SD1_CONFIG SdSpiConfig(36, DEDICATED_SPI, SD_SCK_MHZ(18), &SPI1)
    .
    Not sure if Bill ported the T4 specific uSDHC code (for build-in uSD card) to his library (the "SdFat-beta/src/SdCard/SdioTeensy.cpp" only handles Teemsy3.5 3.6)
    So only SPI may be working
    Bill however reorganized the SdFat-Beta 27 days ago so maybe he is working on something

  25. #3150
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,521
    @WMXZ
    From what I saw the T4 specific uSDHC code for SDIO hasn't been ported over yet. Right now just trying to get the SPI code working for SPI1 on the T4 but can't figure out to get to register to SPI1. The construct that I posted and the option in SDConfig should just use HW SPI going to SPI1 but just seems like it just goes to SPI pins?

    EDIT: At least with the Beta I didn't have to do any modifications to account for the 1062.

Posting Permissions

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