dont forget when you put the sd card in the socket. you flip it over. so pin one is now on the bottom
also my breakout is TD-T40B-A2
if you look at the pinout card, pin 39 at the red end actually connects to 34
I used a 'scope probe and actually tested under power. and saw the signals I did and recorded on that post. those signals are in the wrong spots for the sd card
Very confusing with pins swapping across Card sizes in Four-bit SD bus mode :: https://en.wikipedia.org/wiki/SD_card
and orientation is odd too - top side view above odd where pins on the bottom.
@firehopper - @defragster - @KurtE
@firehopper - my sincerest apologies - but believe you are absolutely correct, pins connections are reverse on the SD Card Connector! Good catch! My mistake is that I forgot to flip the cable connections when you flip the board over.
@mjs513...
That was what I wondered back in the posting: https://forum.pjrc.com/threads/57122...l=1#post216075
![]()
@mjs513 @firehopper ...
Yep -
As I mentioned in that previous posting, when I assembled the first board that I did for the T4, nothing was working, and so I plugged in the sparkfun adapter and did the blink the pins
test. and found that what I expected in DAT1 ended up on DAT2 (opposite end)... Actually I also then double checked on the IO pins I had put on my board and it also went to the wrong pins. My mistake was I forgot to reverse things, when laying out the board, is the direction on the board the connector is pointing, which in using the ribbon cable, the ribbon sort of folded in half and the cable went into the front of the connector and not like a logical straight through shot...
Sort of a similar mistake...
Certainly shows why they didn't work for usStill wonder what I did to get #36 messed with and @mjs513's #38 possibly?
I never tested anything against the wires in the SD connector - as setup I needed to have USB connected - so took all of that as good and never went to verify pin ordering.
@loglow - hopefully that helps you for your next effort - though rework and changes![]()
I remember that board KurtE - I got a set of them - but PCB too thick as ordered, Worked at thinning it a bit but never had need for it …
I put another set of LoPro headers on the bottom to access all pins - since the other side wrongly went on bottom {and pin card reads from top - … must watch 5V!} . Opps - no more taking out the RTC cell.
Also desoldered the SD socket since it was not usable - pads are clean and healthy, no reason seen there for issues.
I wrote an xx=3 test that is an alternate to the Single Pin KurtE PinTest - it cycles all NUM_DIGITAL_PINS. First setting pinMode (see below) then doing USB print of any change from prior value.
"PULLDOWN :: TEST to 3.3V" ::Code:This is current code for xx=0,1,2,3 testing:: TallDog_SDIOpinTest.ino @ALL - interesting if this works as expected on the breakout, and if it shows any anomalies.
Initial setting is PULLDOWN looking for any pin sitting HIGH and announces it during the pinMode loop, records state 5us after setting and indicates if it didn't take the expected state { one pin was lagging }.
>> Any change from recorded state is announced to USB Serial.
Any Serial USB input causes it to toggle, if PULLDOWN then it goes to PULLUP, and the reverse repeats the above - except w/20us wait as below to allow state change.
"PULLUP :: TEST TO GND" ::
Going to PULLUP looking for any pin sitting LOW and announces it, records state 20us after setting and indicates if it didn't take the expected state.
>> Any change from recorded state is announced to USB Serial.
There is at least a partial catch for multiple pins changing per 'test cycle' - pauses cycle 50ms on any change per test and on multiple changes something like this shows instead of one change per line:That is just the SETUP for those xx=3 modes - it will catch pins that are unstable or PULLed opposite of the test expectation:
>> Once in that mode it is a dynamic touch test with USB output with desired pin and the indicated line GND or 3.3V.
When in "PULLDOWN :: TEST to 3.3V" put a Jumper wire to 3.3V and touch any single pin in turn and it should show that pin rise to 1 and drop to 0 on removal, with no other pins following.
… hit SerMon ENTER ...
When in "PULLUP :: TEST TO GND" put a Jumper wire to GND and touch any single pin in turn and it should show that pin drop to 0 and rise to 1 on removal, with no other pins following.
The multi PIN change ">>>" indication was an after thought and might need refinement or UI cleanup, but if on a single pass a single pin touch shows more than one pin change it indicates those pins are not independent or properly functional to the MCU.
RESULTS::d#=34 val=0,d#=39 val=0,>>>
> On PULLDOWN p#36 is always drifts HIGH, GND does show a zero - but one w/GND removed.
> And on PULLUP #37 drifts HIGH, then LOW when untouched - in fits repeatedly then quiet. ALL is quiet on PULLDOWN
Some other pins don't act right - too late to catalog them. Somehow at one point - twice in fact - I had to do 15s Restore of T4.
> Once after soldering the second header row PC didn't see it - I think it was left with good code? Bootloader would go RED and even that was unseen.
> The other time during early code updates - not sure why that was.
Last edited by defragster; 09-23-2019 at 08:42 AM.
@defragster decided to give you XXX=3 pin test a shot, got these results for reference on my board with the SD card socket still attached:
Note pullups on board.Code:PULLDOWN Start Vals: PULLDOWN :: TEST to 3.3V d#=0 val=1,0,0,0,0,0,0,0,0,0, d#=10 val=1,0,0,0,0,0, d#=16 val=1, d#=17 val=1, d#=18 val=1, d#=19 val=1,0,0,0,0, d#=24 val=1, d#=25 val=1,0,0,0,0,0,0,0,0,0,0,0,0,0,0, PULLUP :: TEST TO GND PULLDOWN :: TEST to 3.3V d#=0 val=1 d#=10 val=1 d#=16 val=1 d#=17 val=1 d#=18 val=1 d#=19 val=1 d#=24 val=1 d#=25 val=1 d#=34 val=1 d#=36 val=1 d#=34 val=0,d#=36 val=0,>>> >>> >>> >>>
On one of my breakout boards I get (no canfd transceiver:
On PRJC's breakout (CanFD transceiver on pins30/31:Code:PULLDOWN Start Vals: PULLDOWN :: TEST to 3.3V 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, PULLUP :: TEST TO GND PULLDOWN :: TEST to 3.3V PULLUP :: TEST TO GND PULLDOWN :: TEST to 3.3V
Code:PULLDOWN Start Vals: PULLDOWN :: TEST to 3.3V 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, d#=30 val=1, d#=31 val=1,0,0,0,0,0,0,0,0, PULLUP :: TEST TO GND PULLDOWN :: TEST to 3.3V d#=30 val=1 d#=31 val=1
Last edited by mjs513; 09-21-2019 at 01:44 PM.
anyone heard from @loglow lately?
Cool - it seems to work as expected.
Not sure this is 'neutral / good'?
d#=34 val=1
d#=36 val=1
d#=34 val=0,d#=36 val=0,>>>
That is just the SETUP for those modes - it will catch pins that are unstable or PULLed opposite of the test expectation:
Not sure if it was clear and this was tried?
When in "PULLDOWN :: TEST to 3.3V" put a Jumper wire to 3.3V and touch any single pin in turn and it should show that pin rise to 1 and drop to 0 on removal, with no other pins following.
… hit SerMon ENTER ...
When in "PULLUP :: TEST TO GND" put a Jumper wire to GND and touch any single pin in turn and it should show that pin drop to 0 and rise to 1 on removal, with no other pins following.
The multi PIN change ">>>" indication was an after thought and might need refinement or UI cleanup, but if on a single pass a single pin touch shows more than one pin change it indicates those pins are not independent or properly functional to the MCU.
With four possible tests - rather than recompile setup() could present a MENU list and take USB input to set "xx= ??" and then run to loop().
Could add a 5th test reading HI/LOW on digital pins and analogRead() value on the 14 analog pins, then put out a changing PWM value from Pin_0?
>> like with read/write resolution of 12 bits :: uint32_t outPwmVals[] = { 0, 682, 1364, 2020, 2060, 2728, 3410, 4092 };
Digital should show LOW through 2020, then HIGH above that, and Analog pins should match - each held for 120 ms?
Last edited by defragster; 09-21-2019 at 07:16 PM.
I got a message that said stuff would ship this past thursday. so no idea what happened. Have to wait and see I guess. havent decided if I'm gonna desolder the sd card socket and try and rewire it myself but thats lots of tiny wires![]()
I dont have any wire wrap wire. might have some enameled wire somewhere.
Further to my message #81: Thanks very much lowglow for this information and offer of purchasing the connectors for me.
Short version: Samtec enables us to order any quantity of any connector, with very low shipping costs. However, the website does not show the shipping costs and I had problems confirming my email address when I was using the website to prepare an order. I suggest writing to them if you have any such troubles.
Here is my experience of ordering from Samtec.com: I entered my credit card details, and while that looked as if this would finalise the order, there were further steps before the order was complete. I ordered two items:
3 x TSM-105-01-F-DV @ $0.681 = $2.04
6 x TSM-105-01-F-DV @ $0.763 = $4.58
These prices are from the invoices. The website truncates the per-unit price to cents.
I had been advised "if you ship UPS ground on Samtec’s account, the freight charge will be 4% of the total line value".
I did not know where the connectors would be shipped from. I selected "UPS Express" and placed the order on 16th September. The two sets off connectors were shipped from Singapore on the 18th and 20th. The first arrived today (23rd) and the shipping cost was USD$0.08! The second order's shipping cost was USD$0.18.
Initially I guessed that there would be MOQs, high freight costs etc. Samtec is American, founded in 1976: http://suddendocs.samtec.com/literat...y_original.pdf
The 3D models in the configurator, such as https://www.samtec.com/products/tsm are brilliant. They build and ship connectors quickly and the freight costs for small orders are exceedingly attractive.
Hey all!
You guys are awesome.
Got home safely, but then had a crazy busy weekend.
Looks like I have some work to do!
I should be able to make revisions this week. I might hold off on sending out more kits until the next round of board revisions. I’m excited to fix and refine things. I’m happy to hear initial reports regarding the USB working at least.
I should be able to catch up on this thread in detail as well as my PMs tomorrow evening.
Thanks again,
Dan
glad you had a safe trip. and its gonna be fun to try and fix it with enameled wire