Ah sweet it auto completed the version.
adafruit/Adafruit NeoPixel@^1.8.0
Hmm… but latest one is 1.11.0
@runger You where right, it does compile the basic example. Awesome!
Do you have GutHub Co-Pilot? Or maybe you had 1.8.0 already downloaded? I’d use the newest version, in any case.
Yes I think so,
The Neopix lib alone is quite beefy?
Flash: [== ] 22.8% (used 29840 bytes from 131072 bytes)
There are some remarks that the neopixel lib uses more memory than the original Apollo flight program, lol. You can bit bang it though maybe?
Were you able to get this to work? In my cube config it says you can’t use HSI clock for USB (or not supposed to, for PLL gen, which goes to USB later anyway). It gives an error on code generate.
This look really clean:
STM32_NEOpixels_timer/main.c at master · OutOfTheBots/STM32_NEOpixels_timer (github.com)
Huh, interesting. Are you on the same MCU, the STM32G431VB?
No, on my side it seems pretty happy with that, and its also the generated clock code that I committed in the GitHub.
it’s not the HSI tray feeds the USB, its the extra “HSI48 RC”, whatever that is.
@Juan-Antonio_Soren_E does it produce serial output over USB? The project should be configured for it, I believe.
Ah, I didn’t realize the G431 had a different set of internal clocks. No, I was trying to build for STM32F103xx. I don’t have the same HSI48, just the regular HSI(8MHz in my case). Guess I will need a crystal after all (still drawing up board, just trying to verify as I go with CUBE).
It says DFU in FS mode (Device Manager)
Maybe it is the BOOT0 pin, should I disable that?
@runger Good thing is it recognizes the USB device and makes the typical windows sound !
Mkay, I checked the “Run after programming” box in Cube_Programmer, and now it says USB device not recognized. Its like its missing a driver ?
A request for the USB device descriptor failed.
Ha, thats weird. When it was in DFU mode I could flash it over USB and now the Adafruit NeoPix program runs.
Hello world !
After a reset, it then goes back into DFU mode …
That’s great! If that’s the case then everything is working to a large extent, and also the USB programming is working (no reason it shouldn’t, of course) which will be more convenient for you than the SWD-pogo-thing.
Ok, then I would say your boot0 needs a pull-down, or to be disabled by fuse if that’s possible.
You could try adding a Serial.begin(115200); and some output and see if that makes it show up on USB as a serial port too…
Yub, that did the trick. Just un-checked nSWBOOT0 and the device is now on PORT5 also after reset.
Do you think I can flash it through the USB at this point?
--- Terminal on COM5 | 115200 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H
HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!HELLO WORLD!
Building in release mode
Checking size .pio\build\funqistack_stspin32g4\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [= ] 13.6% (used 4460 bytes from 32768 bytes)
Flash: [=== ] 28.4% (used 37200 bytes from 131072 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio\build\funqistack_stspin32g4\firmware.elf
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-16-21:19)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 1
hla_swd
Error: open failed
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked
Tried to change upload_protocol to serial but got error:
http://stm32flash.googlecode.com/
Failed to init device.
Using Parser : Raw BINARY
Interface serial_w32: 115200 8E1
*** [upload] Error 1
A workaround would be to put the target into DFU deliberately by way of software trigger. Which is rather annoying and tedious. Like sending “DFU” to the MCU could make it run a function to trigger the DFU state.
If you set the upload_protocol = dfu, in platformio.ini does it help?
There might already be a way to force it into bootloader mode from USB Serial, but I am not sure if it is implemented or not.
Nope I did try that. It really is no biggy. We are set for upup and away programming.
There should be some internal I2C going on between the MCU and the Driver / Buck & LDOs. That’s actually a good place to start. Is it the Wire lib.?
Wire lib and I2C3 (should maybe be Wire3 ?). I can look into later on. I defined the pins in the header file I believe…
Ive tried to use the Wire.h I2C scanner. But there are no slaves on the bus. I think hardware I2C needs to be initiated for the specific pins.
this is from the PeripheralPins.c
//*** I2C ***
#ifdef HAL_I2C_MODULE_ENABLED
WEAK const PinMap PinMap_I2C_SDA[] = {
{PA_8, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C2)},
{PA_14, I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C1)},
{PB_5, I2C3, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF8_I2C3)},
{PB_7, I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C1)},
{PB_9, I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C1)},
{PC_9, I2C3, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF8_I2C3)},
{PC_11, I2C3, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF8_I2C3)},
{PF_0, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C2)},
{NC, NP, 0}
};
#endif
#ifdef HAL_I2C_MODULE_ENABLED
WEAK const PinMap PinMap_I2C_SCL[] = {
{PA_8, I2C3, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF2_I2C3)},
{PA_9, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C2)},
{PA_13, I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C1)},
{PA_15, I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C1)},
{PB_8, I2C1, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C1)},
{PC_4, I2C2, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF4_I2C2)},
{PC_8, I2C3, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_NOPULL, GPIO_AF8_I2C3)},
{NC, NP, 0}
};
#endif
Ok, Ive managet to read from the driver I2C register.
I set it up like this:
int I2C_Internal_Adr = 71; //
TwoWire myWire2(INTERNAL_I2C3_SDA, INTERNAL_I2C3_SCL);
myWire2.beginTransmission(I2C_Internal_Adr); // Begin transmission to the Sensor
//Ask the particular registers for data
myWire2.write(0x02);
myWire2.endTransmission(); // Ends the transmission and transmits the data from the two registers
myWire2.requestFrom(I2C_Internal_Adr,1); // Request the transmitted two bytes from the two registers
while(myWire2.available()) // slave may send less than requested
{
int c = myWire2.read(); // receive a byte as character
Serial.println(c, HEX); // print the character
Serial.println(c, DEC);
Serial.println(c, BIN);
}
If I point to adress 0x02 and read 1 byte i get this answer:
73
115
1110011
If I point to 0x80 it send a different answer.
Reading the 0x07 returns:
nFAULTState = HIGH
READYState = HIGH
9
9
1001
Reading 0x09 returns:
FF
255
11111111
Hmm… Reading from 0x01 register returns;
0
0
0
Very nice! I will write a I2C driver for all this when I get my boards done…
Ok, cool.
Is it right to assume, that sending 01 (BIN) to Address 0x01 (POWMING) will set the buck to 10v. So actually 0x01 twice? Or should it be 10?