Teddycloud CC3200 newbie guide

[derGreyson]

And here both lights with power supply

[henryk]

Is The sd Card still in Place? Iirc the light was Green when i did it yesterday.

Is the Box working fine if you reassemble it now?

[derGreyson]

i copied this are you sure it is the RTS Pin? Cause in the Picture above it is called the RST PIN. OR do i have to connect the RTS on my UART to GND?

[henryk]

Most likely it is a typo. Will fix that later.

[derGreyson]

I had flashed the SD Card. Because i was stupid. But i flashed it again to FAT32 and it worked.

I have now just 1 Directory in my SD card.

Content/00000000
Content/00000001
Content/450E230E

but no other trashcan like in this video

Wir HACKEN die Toniebox!

[derGreyson]

do i have to get Power to Pin 3 AND 9?

Like writen in this post?

Timed out while waiting for ack

Here is a drawing of my wiring: [Wiring] Does this help? Has anyone before used a logic analyzer to log the communication between PC and Toniebox? I hoped that comparison between good case and my case could give some hints what I am doing wrong… The Toniebox board is only connected to the speaker, but not to the ears.

[henryk]

Don’t know.

I followed the guide and it worked as it should. Please check your equipment if its working fine and if your Clamp has the expected wiring (maybe the first row is actually the second and the second the first?). For me it looks like you are doing everything correctly.

[derGreyson]

I am such an Idiot… you are right. Wrong line.

So if the PCB is glowing RED your are wrong with the lines.

[jrel12304]

Hey, I am struggling with the connection for flashing the box. I connected the UART, the green light is lightning. But still, lsusb / cc3200tool is not showing anything helpful.
If I plugin in the device, the following two devices will be added to lsusb:
Bus 001 Device 001: ID 1a86:7522 1a86 USB Serial
Bus 000 Device 000: ID 1a86:7522 1a86 USB 3.1 Bus

I am on macos 15.2, using the cc3200tool branch with the ftdi://ti:launchpad:cc3101/2 connection way. I use the original USB-C cable. board is a cc3200r1.

UART: Weiact ch340k ch340 usb zu serial/ttl uart modul 3,3 v ttl auto download - AliExpress 7

any idea how to solve that issue? thanks!

[clfberlin]

Thanks for the structured guide! I am still coping with getting my CC3200 box connected to the Teddycloud, so I will restart the process using your guide. Hotglue for the wires is a great idea!
One suggestion regarding the server certificate: What I did was use the Portainer console to copy the ca.der to /teddycloud/data/www/web. I was then able to download it on my other machine via browser http://[teddycloud-ip]/web/ca.der
Cheers

[henryk]

In the next version the download of the ca.der (tc) will be available in the gui also (preview available in develop version already )

[Carl_We]

Hello chuckf,

thank you for your detailed answer and help. I am now finally after christmas one step further.

I have followed your instructions except that I no longer use AdguardHome.

- TC reinstalled
- Use the TC patch
- Teddycloud works properly and now displays the following

INFO |server.c:0959:server_init| 1 open HTTPS API connections
INFO |server.c:0959:server_init| 0 open HTTPS API connections

- The box reports after freshness-check: Codeword owl

The question now is whether I have to repatch the box after reinstalling TC?
So only this step? or the whole instruction of the cc3200 tool? Is this about the Teddycloud or Boxine cert?
cc3200tool --reset dtr -p /dev/ttyUSB0 write_file /home/pi/cc3200tool-env/server/ca.der /cert/c2.der

zertificates teddycloud

~/teddycloud/certs/client$ ls
ca.der client.der private.der

~/teddycloudfolder/certs/server$ ls
ca-key.pem ca-root.pem ca.der teddy-cert.pem teddy-key.pem

[marco79cgn]

@Carl_We

The question now is whether I have to repatch the box after reinstalling TC?
So only this step? or the whole instruction of the cc3200 tool? Is this about the Teddycloud or Boxine cert?
cc3200tool --reset dtr -p /dev/ttyUSB0 write_file /home/pi/cc3200tool-env/server/ca.der /cert/c2.der

If you did a clean new teddycloud installatioin (and also deleted the former volumes where the certificates are stored), teddycloud created new server certificates upon its first start (in /teddycloud/certs/server inside the container). So you have to write exactly this certificate (/teddycloud/certs/server/ca.der) onto your Toniebox with the command you already posted (→ /cert/c2.der). Reboot the Toniebox afterwards and it should work.

You can access the teddycloud volumes outside the container (on your Docker host machine) using the directories of this output:

docker inspect -f '{{range .Mounts}}{{.Type}}: {{.Source}} => {{.Destination}}{{println}}{{ end }}' teddycloud

Default should be /var/lib/docker/volumes/teddycloud_certs/_data/server/ca.der, but depending on your Docker host OS and your docker-compose.yaml, this might vary.

[Carl_We]

Very good, then I’ve finally got it right. Here is my approach with unfortunately sobering results.

1. docker cp teddycloud:/teddycloud/certs/server/ca.der /home/pi/
2. cc3200tool --reset dtr -p /dev/ttyUSB0 write_file /home/pi/ca.der /cert/c2.der

2025-01-05 20:01:54,015 – Connecting to target…
2025-01-05 20:01:56,381 – timed out while waiting for ack
2025-01-05 20:01:58,653 – timed out while waiting for ack
2025-01-05 20:01:58,924 – Connected, reading version…
2025-01-05 20:01:58,939 – connected to target
2025-01-05 20:01:58,940 – Version: CC3x00VersionInfo((0, 4, 1, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2025-01-05 20:01:58,940 – This is a CC3200 device
2025-01-05 20:01:58,941 – Switching to NWP bootloader…
2025-01-05 20:01:58,955 – Switching UART to APPS…
2025-01-05 20:01:58,971 – Resetting communications …
2025-01-05 20:02:00,250 – Uploading rbtl3100s.dll…
2025-01-05 20:02:00,251 – Reading rbtl3100s.dll from file /home/pi/cc3200tool-env/lib/python3.11/site-packages/cc3200tool/dll/rbtl3100s.dll
2025-01-05 20:02:00,252 – Getting storage list…
2025-01-05 20:02:01,177 – APPS version: CC3x00VersionInfo((0, 4, 0, 2), (0, 0, 0, 0), (0, 0, 0, 0), (0, 0, 0, 0), (16, 0, 0, 0))
2025-01-05 20:02:01,193 – File exists on target, erasing
2025-01-05 20:02:01,209 – Erasing file /cert/c2.der…
2025-01-05 20:02:01,353 – Uploading file /home/pi/ca.der → /cert/c2.der [1419, disk=1419]…
.
2025-01-05 20:02:01,625 – Read file after writing for verification…
2025-01-05 20:02:01,641 – Reading file /cert/c2.der → /tmp/tmp8sr1gwly
2025-01-05 20:02:01,722 – File /cert/c2.der verified
2025-01-05 20:02:01,723 – Getting storage info…
2025-01-05 20:02:01,738 – storage #2 info bytes: 0x10, 0x0, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0
2025-01-05 20:02:01,739 – Getting storage list…
2025-01-05 20:02:01,753 – Reading raw storage #2 start 0x0, size 0x2000…
…
2025-01-05 20:02:01,884 – [1] detected a valid FAT revision: 125
2025-01-05 20:02:01,885 – Getting storage list…
2025-01-05 20:02:01,899 – Reading raw storage #2 start 0x1774, size 0x2774…
…
2025-01-05 20:02:02,068 – selected FAT revision: 125 (active)
2025-01-05 20:02:02,071 – FAT r125, num files: 29, used/free blocks: 941/83
2025-01-05 20:02:02,071 – All commands done, bye.

// then the box lights up green and can only be restarted by disconnecting and reconnecting the battery, reset does not work

3. freshness check codeword: owl

Do you have any ideas where I made a mistake? Unfortunately I ran out of mine.
Thank you again.

(cc3200tool-env) pi@raspberrypi:~ $ docker exec -i teddycloud bash < check-certs.sh

Checking teddyCloud certificates…

server/ca.der: OK
server/ca-key.pem: OK
server/ca-root.pem: OK
client/ca.der: OK
client/client.der: OK
client/private.der: OK
*/ca.der: File not found!
*/client.der: File not found!
*/private.der: File not found!

[marco79cgn]

Writing the certificate obviously worked according to your logs.

Can you show your ngCfg.json? Which patches have you used there?

[Carl_We]

I am currently using the altUrl.tc.fritz.box but I have tried the altCa.305 before.

"general": {
    "activeImg": "ofw2",
    "_descWaitForPress": "Waits for an earpress on startup",
    "waitForPress": false,
    "_descWaitForBoot": "Waits for an earpress before firmware boot",
    "waitForBoot": false,
    "waitTimeoutInS": 60,
    "_descMinBatteryLevel": "Divide through 2785 to get voltage",
    "minBatteryLevel": 8869,
    "ofwFixFlash": "/sys/pre-img.bin",
    "_descSerialLog": "Logging only works with the debug build!",
    "serialLog": false,
    "_descLogLevel": "0:Trace - 5:Fatal",
    "logLevel": 0,
    "_descLogColor": "Use colors in log output",
    "logColor": false
},
"ofw1": {
    "checkHash": false,
    "hashFile": false,
    "watchdog": true,
    "bootFlashImg": true,
    "flashImg": "/sys/pre-img.bin"
},
"ofw2": {
    "checkHash": true,
    "hashFile": false,
    "watchdog": true,
    "ofwFix": true,
    "ofwSimBL": true,
    "patches": ["altUrl.tc.fritz.box"]

[henryk]

Why aren’t you using the alt ca patch? Have you wrote the teddycloud ca as ca.der into your firmware image? Only in this case it will work without the patch.

[Carl_We]

Do you think it should work as follows?
“patches“: [”altCa.305”, ‘altUrl.tc.fritz.box’]

What exactly do you mean by writing ca.der in the firmware?

[henryk]

There is one step where you should write the ca.der from tc as c2.der into the firmware. That’s what I meant.

And yes, if you followed the guide, adding the altCa patch can help

[Carl_We]

@henryk
this was the solution [”altCa.305”, ‘altUrl.tc.fritz.box’]. Thank you very much!
and even @marco79cgn thx for your great help!