Hi there!

[billj324]

firmware loaded, driver installed correctly, sees adapter. No communication from or to chip. Oscilloscope-checked, no outputs coming from anything. Am I missing something?

[dossalab]

firmware loaded, driver installed correctly, sees adapter. No communication from or to chip. Oscilloscope-checked, no outputs coming from anything. Am I missing something?

Hi, sorry for the late reply. Can you elaborate more on what your setup is exactly? I tested my own board with bqStudio and it definitely tries to communicate with the chip and do auto-probing. Are you doing the same? Do you see commands being recognized by the probe (led blinking as you fire up the studio)?

[billj324]

I apologize for the delay... I attempted to compile it my self with errors (posted that on another issue), but Instead, I downloaded from releases, added it to pico, GPIO 0,8,9 active. connected to wires to battery C and D. BQ2084 evaluation V1.3.0. Sees card but no communication from the 40z551 chip. Do I need to provide 5v to "B" wire and ground? Ideas?

[dossalab]

What software do you use? NLBA or bqStudio?

[billj324]

Use three different, NLBA, bqStudio old and new. all three see the adapter. I dont have a realistic oscilloscope yet, using something... pico based. not seeing any signal from the GPIO 8 or 9. Oscilloscope works (but could still be the problem with detecting the signal) son & I built project to show effect of changing field... added pull-ups, no effect. Interested in helping more in depth - tell me what I can do

[dossalab]

That's strange, bqStudio sends tons of commands on startup and you should definitely see some data coming out from I2C. Did you try capturing as you run the studio (while bqStudio banner is on the screen)?

[billj324]

I got the oscilloscope isolated now, and everything coming in is super clean. What I'm seeing is 3.3V on GPIO 8 and 9 and 1. no clock no signal. I add a pull-up and its of course drops. but no signal, just voltage. Perhaps the gpio pins not set? Using this on pico w fwiw

[dossalab]

The fact that you see 3v3 on these pins makes sense as they are in fact configured by the firmware (1 is UART TX for debug output). I'm not sure whether pullups are necessary - seems like you already have the correct levels - I personally did not use them in some of the experiments, just connected to battery module directly and got sensible results.

I still think the problem is the procedure you're using or the software. Can't suggest anything else besides digging deeper and getting logs from the firmware....

[billj324]

So... to spare the long message: got scope working, CAN see something from UART GPIO1, Can see 3v3 on GPIO8/9, but no activity. using bqstudio, I tell it to scan addresses, GPIO1 lights up, no activity on the others. Using Pico W. Im guessing its time to set up debug tools and the other pico, and learn some new things

[dossalab]

Ah sorry, PicoW does not have LED attached at GPIO25 hence you can't see it blinking :) Normally it should blink the onboard LED once it sees requests from the host. You might need to connect an external LED to see it working. I don't have PicoW so I never tried the firmware on it.

[billj324]

Where in the code can I change the GPIO25?

[billj324]

for reading the serial out, I may need help with this. Im guessing I need a USB->UART, and from there, using the defmt command with the right things plugged in, I should be able to log? I'm learning so much in parallel to this my head is spinning.

[dossalab]

Where in the code can I change the GPIO25?

It's in src/main.rs, in macro assign_resources!. You can change the green field value to any pin number you want.

Im guessing I need a USB->UART

Yup.

using the defmt command with the right things plugged in

Yes, as far as I remember you need to install defmt-print utility, then you pipe incoming serial data to this utility to decode the messages (something like socat /dev/ttyUSB0,rawer,b115200 STDOUT | defmt-print -e path/to/your/compiled/binary). You need original binary (elf) for it to work correctly.

I don't know whether there's a more user-friendly way of doing that unfortunately :disappointed:

[billj324]

It sounds like that is the user-friendly way to do it lol. I just need to exercise my brain a little. Thank you for pointing me in the right direction. I gave it my best effort to look for the GPio25 before asking. I appreciate your help!

[billj324]

ok... so after 3 hrs of learning.... I started over. GIT cloned the repo, skip a few details, got it to compile (no errors on first try). the ti-i2c binary that it spits out in the target dir is waaaay smaller than what's on the releases. So I discarded it, and instead downloaded what I assume to be the compiled binary from releases. I was able to create the ELF file from it. Unfortunately, I don't have a Blackmagic probe ( I will likely get it because it looks really useful), so I'm using openOCD instead. it may take a while before I get much further to see if the ELF I created works. Questions: main.rs throws a warning in Vscode: can't find crate for test can't find craterustc

Could this be why the ti-i2c file is much smaller than supposed to be or am I missing something?

The ti-i2c file the compiler spit out using cargo build, was only found in ev2400-on-raspberry-pi-pico\target\thumbv6m-none-eabi\debug, and is only 3,856kb I tried to run cargo build --bins with same result except now ti-i2c appears in repo's main. pls edumacate me good sir

[dossalab]

The binary in the releases is build in release profile (cargo build --release) and it's 66 kb, yours is most likely debug and it's 3856 kb (that is 3.8 megabytes, not 3.8 kilobytes :grin:) I don't know much about these VS code warnings, but if you're able to produce a binary that should be good enough. You should be able to view logs with both release and debug profiles. If you have any other probe that is compatible with rp2040 you can use it as well - though it's not strictly required (it makes it quicker to upload the code to the chip, but logging itself is possible without the dedicated debugger).