Hello, i brought this screen off Ali Express that uses an NV3007 drivee but i cant seem to find any examples code for it.

https://a.aliexpress.com/_Ezf9zM6/

Has anyone had any experience of using this lcd driver and be able to point me to any resources to get up and running?

Thank you!

so just to prove that the thread switcher i build works i have uploaded video of it blinking 5 leds at once (a python script reads uart and lights that led ) also i confirmed the bulb is fine works .

#define GPIO_C *((volatile uint32_t*) 0x40020818u)//bsrrgpioc

RCC->AHB1ENR |= RCC_AHB1ENR_GPIOCEN;//= 0x00000004u ;// clock enable bit2->portc

(void)RCC->AHB1ENR; // <-- dummy read, forces the enable to take effect

*((volatile uint32_t*) 0x40020800u) &= ~(3<<26) ;// clear 26th and 27th bit

*((volatile uint32_t*) 0x40020800u) |= (1<<26) ; //moder26thbit>>

void blue(void) {

while (1) {

// Wait until UART is free, yielding the CPU to other threads

while (uart_lock == 1) {

rtos_yield();

}

uart_lock = 1; // Claim lock

HAL_UART_Transmit(&huart1, (uint8_t*)"b0\r\n", 4, 8);

uart_lock = 0; // Release lock

// Sleep for 500ms (50 ticks @ 100Hz)

rtos_delay(50);

}

}

void green(void) {

while (1) {

while (uart_lock == 1) {

rtos_yield();

}

uart_lock = 1;

HAL_UART_Transmit(&huart1, (uint8_t*)"g0\r\n", 4, 8);

uart_lock = 0;

// Sleep for 300ms (30 ticks @ 100Hz)

rtos_delay(30);

}

}

void red(void) {

while (1) {

while (uart_lock == 1) {

rtos_yield();

}

uart_lock = 1;

HAL_UART_Transmit(&huart1, (uint8_t*)"r0\r\n", 4, 8);

uart_lock = 0;

// Sleep for 100ms (10 ticks @ 100Hz)

rtos_delay(10);

}

}

void yellow(void) {

while (1) {

while (uart_lock == 1) {

rtos_yield();

}

uart_lock = 1;

HAL_UART_Transmit(&huart1, (uint8_t*)"y0\r\n", 4, 8);

GPIO_C = (1ul<<13);

uart_lock = 0;

// Sleep for 200ms (20 ticks @ 100Hz)

rtos_delay(20);

}

}

void white(void) {

while (1) {

GPIO_C = (1ul<<29);

while (uart_lock == 1) {

rtos_yield();

}

uart_lock = 1;

HAL_UART_Transmit(&huart1, (uint8_t*)"w0\r\n", 4, 8);

uart_lock = 0;

// Sleep for 400ms (40 ticks @ 100Hz)

rtos_delay(40);

}

}

Hey, working on my first big STM32 project and want some
feedback before I commit to the schematic.

What I'm building:
A pure USB to DAC bridge. Laptop does all the DSP with
CamillaDSP (crossovers, EQ, room correction). The STM32
just moves audio from USB to 16 DACs. No processing on
the chip itself. Goal is 128 output channels for active
crossover setups.

MCU: STM32H743IIT6
USB: USB3300 ULPI for High Speed
Outputs: 128 channels via 8x SAI TDM-16 lines

What I have in the pinout so far:
- USB HS ULPI (all 12 pins)
- 8 SAI data lines for 128 channels
- 4 I2C buses (DAC config + direct volume control)
- 16 individual DAC reset pins
- SPI LCD with CS, DC, RST, and PWM backlight
- Rotary encoder on TIM5 + push button
- 9 back panel buttons (undecided purpose)
- External trigger input
- Amp trigger output
- Status LED
- Fan PWM
- USB PHY reset
- SWD

Still have 64 GPIO free.

What I'm asking:
1. Any features I should add while I have the pins free?
2. Anything stupid in my pin choices you can spot?
3. Anyone worked with SAI4 on H743? It's in D3 domain
and I'm not 100% sure syncing it with SAI1 will work
the way I want.

Screenshot of the pinout below. Roast it if needed.
4. You got any great pin mapping advice I am beginner Idk shit I just did it what I thought was good as I am gonna make my own pcb I need a great pin mapping so pcb design is easy as hell
5. Btw I would add any silly feature you suggest

Everytime I want to upload a new firmware, I basically get a comms timeout “lost communication with board” on Mission Planner.

I have a pixhawk 6C. When I boot up it’s COM4 until that pixhawk tune chimes in and then I see COM7 and COM9. I can connect successfully but as soon as I want to upload firmware it switches to COM4 and get “lost communication with board”

I’ve already tried STM32Bootloader twice, and no success. I used another computer and usb cable all with no success…

Any tips?

I AM TRYING TO WRITE A DRIVER FOR STM32F411RE NUCLEO BOARD TO OUTPUT 16 BIT AUDIO AT 44.1KHZ VIA A PCM5102 DAC. ITS BEEN DAYS WRITING THIS BUT FROM YESTERDAY I AM TESTING AND NOTHING IS HEARD ON THE OUTPUT SIDE OF THE DAC. I AM OUT OF MY CITY SO I HAVE NO OSCILLOSCOPE OR ANYTHING. CAN YOU GUYS PLEASE HELP ME REGARDING ANY ISSUES YOU SEE HERE.

int main(){

// ENABLING CLOCK TO GPIOA
RCC_AHB1_ENR |= (1<<0);
// ENABLING CLOCK TO GPIOB
RCC_AHB1_ENR |= (1<<1);
// ENABLING CLOCK TO SPI2 == I2S2
RCC_APB1_ENR |= (1<<14);
// SETTING PA3=SCK/MCK AND PB9=LCK/WS, PB10=BCK/CK, PB15=DIN/SD TO ALTERNATE FUNCTION MODE
GPIO_A_MODER |= (1<<7);
GPIO_A_MODER &= ~(1<<6);

GPIO_B_MODER |= (1<<19);
GPIO_B_MODER &= ~(1<<18);

GPIO_B_MODER |= (1<<21);
GPIO_B_MODER &= ~(1<<20);

GPIO_B_MODER |= (1<<31);
GPIO_B_MODER &= ~(1<<30);

// MAKING THEM AS FAST AS POSSIBLE
GPIO_A_OSPEEDR |= (1<<7);
GPIO_A_OSPEEDR |= (1<<6); //PA3

GPIO_B_OSPEEDR |= (1<<19);
GPIO_B_OSPEEDR |= (1<<18); //PB9

GPIO_B_OSPEEDR |= (1<<21);
GPIO_B_OSPEEDR |= (1<<20); //PB10

GPIO_B_OSPEEDR |= (1<<31);
GPIO_B_OSPEEDR |= (1<<30); //PB15

// SETTING THE ALTERNATE FUNCTION TO THE I2S2 FUNCTIONS
GPIO_A_AFRL &= ~(1<<15);
GPIO_A_AFRL |= (1<<14);
GPIO_A_AFRL &= ~(1<<13);
GPIO_A_AFRL |= (1<<12);

GPIO_B_AFRH &= ~(1<<7);
GPIO_B_AFRH |= (1<<6);
GPIO_B_AFRH &= ~(1<<5);
GPIO_B_AFRH |= (1<<4);

GPIO_B_AFRH &= ~(1<<11);
GPIO_B_AFRH |= (1<<10);
GPIO_B_AFRH &= ~(1<<9);
GPIO_B_AFRH |= (1<<8);

GPIO_B_AFRH &= ~(1<<31);
GPIO_B_AFRH |= (1<<30);
GPIO_B_AFRH &= ~(1<<29);
GPIO_B_AFRH |= (1<<28);

// CONFIGURING THE NORMAL PLL
RCC_CR &= ~(1<<24); // DISABLING THE PLL
while (  (RCC_CR & (1<<25)) ){} // WAITING FOR PLL TO UNLOCK
RCC_CR |= (1<<16); // ENABLING THE HSE
while(!( RCC_CR & (1<<17) )){} // CHECKING IF HSE IS READY OR NOT
// RCC_CR |= (1<<18); // BYPASSING THE HSI WITH HSE
RCC_PLLCFGR |= (1<<22); // SELECTING HSE AS SOURCE TO BOTH PLL,I2SPLL
// THE HSE IS 8MHZ BY DEFAULT
RCC_PLLCFGR &= ~(0b111111<<0); // PLLM CLEARING
RCC_PLLCFGR |= (0b000100<<0); // PLLM SET TO 4
RCC_PLLCFGR &= ~(0b111111111<<6); // CLEARING THE PLLN
RCC_PLLCFGR |= (0b010101000<<6); // PLLN SET TO 168
RCC_PLLCFGR &= ~(1<<17);
RCC_PLLCFGR |= (1<<16); // MAIN PLL DIV FACTOR FOR SYSCLOCK SET TO 4=PLLP
RCC_CFGR |= (0b01000<<16); // SETTING THE RTC CLOCK WHICH HAS TO BE 1MHZ
RCC_CFGR |= (0b000<<13); // NO APB2 DIVISOR REQUIRED <100MHZ
RCC_CFGR |= (0b100<<10); // APB1 DIVISOR SET TO 2. APB2= 42MHZ
RCC_CFGR |= (0b0000<<4); // NO DIVISOR REQUIRED FOR AHB
RCC_CR |= (1<<24); // ENABLING THE PLL
while (  !(RCC_CR & (1<<25)) ){} // WAITING FOR PLL TO LOCK
FLASH_ACR &= ~(0b1111<<0); //CLEARING THE LATENCY IN FLASH ACR
FLASH_ACR |= (0b0010<<0); // SETTING THE LATENCY TO 2 AS PER FLASH CHAPTER
RCC_CFGR |= (0b10 <<0); // PLL SET AS SYSTEM CLOCK
while(((RCC_CFGR>>2)&3)!=2){} // WAIT TILL PLL SET AS SYSTEM CLOCK
RCC_CFGR &= ~(1<<23); // PLLI2S WILL BE USED AS I2S CLOCK SOURCE

// CONFIGURING I2SPLL
//FROM THE TABLE 90 PG 591 FOR 44.1KHZ 16 BIT AUDIO WITHOUT MCK. THESE ARE OPTIMISED VALUES CHOSEN FROM THEM
RCC_CR &= ~(1<<26); // DISABLING THE I2SPLL
while (  (RCC_CR & (1<<27)) ){} // WAITING FOR I2SPLL TO UNLOCK
RCC_I2SPLLCFGR &= ~(0b11111<<0); //PLLI2Sm CLEARONG
RCC_I2SPLLCFGR |= (0b00100<<0); //PLLI2Sm=4
RCC_I2SPLLCFGR &= ~(0b111111111<<6); //PLLI2SN CLEARING
RCC_I2SPLLCFGR |= (0b010010111<<6); //PLLI2SN=151
RCC_I2SPLLCFGR &= ~(0b111<<28); //PLLI2SR CLEARING
RCC_I2SPLLCFGR |= (0b010<<28); //PLLI2SR=2
RCC_CR |= (1<<26); // ENABLING THE I2SPLL
while (  !(RCC_CR & (1<<27)) ){} // WAITING FOR I2SPLL TO LOCK

// I2S PROTOCOL CONFIG
// I2S MODE SELECTED
I2S2_CFGR |= (1<<11);

I2S2_CFGR &= ~(1<<0); // 16 BIT WIDE CHANNELS
// 16 BIT DATA LNTGH TO BE TRANSFERRED
I2S2_CFGR &= ~(1<<1);
I2S2_CFGR &= ~(1<<2);
// STEADY STATE CLOCK POLARITY???
I2S2_CFGR &= ~(1<<3);
//I2S PHILLIPS STANDARD
I2S2_CFGR &= ~(1<<5);
I2S2_CFGR &= ~(1<<4);

// MASTER TRANSMIT MODE
I2S2_CFGR |= (1<<9);
I2S2_CFGR &= ~(1<<8);
// MASTER CLOCK DISABLED
I2S2_PR &= ~(1<<9);
// ODD=1
I2S2_PR |= (1<<8);
// I2SDIV=53
I2S2_PR &= ~(0xFF<<0);
I2S2_PR |= (0b00110101<<0);

// I2S ENABLED
I2S2_CFGR |= (1<<10);
uint32_t idx = 0;
while(1){
    while(!(I2S2_SR & (1<<1))){}
    I2S2_DR = (uint16_t)furelise[idx];     // left

    while(!(I2S2_SR & (1<<1))){}
    I2S2_DR = (uint16_t)furelise[idx];     // right

    idx++;
    if(idx >= NUM_SAMPLES) idx = 0;
}
return 0; }

I have an Nucleo 144 board, and an Stm32h753zi chip. the board has been working for the past 2 months controlling some closed loop motors, and then suddenly stopped working when i tried flashing a program. When plugged in, the led6 in the top right corner is now red, which means some sort of overcurrent. When i used a multi meter to check, I found that 3v3 was shorted with gnd. 5v is fine. Is the board bricked? or is it a fixable issue? Do you guys have any advice. The left pin of JP4 is also shorted with gnd, but the right one isnt.

I have less than a yr experience in embedded software, and I sometimes use AI for STM32 HAL programming, which leaves me with some guilt🤣(my thoughts are like: you should be learning to memorise these such that you can write code off-head ) . I do try debugging on my own and go back to AI when my efforts are fruitless.

TO THE EXPERIENCED EMBEDDED ENGINEERS OUT THERE, what's your opinion on this? Do you recommend use of AI, and in which scenarios?

Hey guys, I really need some help because I'm completely stuck.

This has now happened with two STM32F411CEU6 Black Pill boards, and I can't figure out what's going wrong.

With the first board, Windows detected the USB without any issues. I flashed a simple LED blink program, which worked perfectly. Then I flashed my actual firmware, and everything ran exactly as expected. The PWM outputs and gate signals were perfect, and I tested the setup for several hours without any problems.

I packed everything up for the day, came back the next morning, plugged the board back in, and... nothing.

Windows no longer detected the USB at all.

I then bought a cheap ST-LINK to see if the MCU was still alive. The ST-LINK could detect that an STM32 was present, but every attempt to connect ended with "Data read failed", and I couldn't erase or reprogram the chip.

I spent hours trying different fixes (including suggestions from ChatGPT), but nothing worked. Since I couldn't recover the MCU, I assumed the board had somehow died and bought a second one.

Now here's the strange part.

I repeated the exact same sequence on the second board. Windows detected it, the LED blink test worked, my firmware flashed successfully, and the PWM and gate signals were perfect. After finishing my testing, I disconnected everything, came back the next day, and the second board has developed the exact same problem.

At this point I'm convinced I'm doing something wrong, but I have no idea what. Why would a board work perfectly for hours and then, after being powered off overnight, suddenly stop being detected over USB?

Has anyone experienced something like this before? Is there anything that could permanently disable the USB interface or damage the STM32 while the board is just sitting powered off?

TL;DR: My first STM32F411 Black Pill worked perfectly (USB detected, firmware flashed, PWM/gate signals working), but the next day it was no longer detected over USB. ST-LINK could see the target but failed with "Data read failed", and I couldn't erase or reprogram the chip. I assumed the board had died, so I bought a second one. I repeated the exact same workflow, and after working perfectly on day one, the second board has now failed in the exact same way. Looking for any ideas on what could be causing this.

Now finally have working FPU support on both Cortex-M7 (tested on STM32H753ZI) and Cortex-M4 (tested on FRDM-K64F).

While adding FPU support, I noticed some mutex bugs I wasn't handling correctly — a task holding a mutex could get preempted mid-FPU-operation and things would go sideways. Fixed now. Already reading real IMU data as a result :)

Priority inheritance for mutex added and verified: when a high-priority task blocks on a mutex held by a low-priority one, the owner's priority gets temporarily boosted so a mid-priority task can't sneak in and cause priority inversion. Verified with a LOW/HIGH/MED task setup over 90+ consecutive cycles with no exceptions.

But this one I'm most happy about: fault logging in battery-backed SRAM. If the board crashes (HardFault, MemManage, etc.), the fault info (faulting address, instruction, which task) survives the reset. Next boot, I get a full report over UART: "here's exactly where you died last time." Debugging became sooooo easy.

Next up: Message Queue and writing a FlexCAN driver for the K64F port so both boards can actually talk to each other over a real CAN bus (ordered a couple of SN65HVD230 transceivers for that).

My plan is to control my own drone with TamgaOS. I hope soon :) — also working on control optimization and XFLR5 on the side.

GitHub: https://github.com/hrasityilmaz/TamgaOs
Devlog: https://auctra.app/

Yeesh, okay. strap in

I have a board that acts as a serial control node.

("Buoys" https://plates.lunchfirm.com/lakehouse/)

It has upstream and downstream USARTs. Because I wanted a virtual com port for bring up but only had these two USARTs available, one of them (the port facing the receiver) is doubled up. So I have USART1 connected to my output connector AND the STDC14 to connect to my stlink v3. Follow so far?

This is obviously a wacky thing to do, and I knew it would bite me somewhere, but for the most part it was not an issue.

I brought up 1 buoy, painless. I brought up a second buoy up the chain, was able to debug all the tasty interactions between two buoys, and noted a mysterious "buoy 2 wont echo my console commands back". I realized this kind of made sense, as its RX line was held captive by the other buoy's TX line.

Then, I brought up the receiver, and everyone worked together magically. I celebrated and went home. Any one buoy in the chain passes its data down the chain to the receiver and everyone is happy.

I come back to the office today, and I can't get either buoy to respond to console commands! This firmware takes care of the echo, so I can tell that nothing is getting through cuz I can't type "version" or anything into CoolTerm. I tried, well, everything...

And it took -way- too long to realize that the freakin' receiver was now, of course, holding my first buoy's RX hostage. My little bad-idea-stlink-VCP-piggy-back regime couldn't get through to the first buoy, or the second buoy, and everyone was confused.

Claude, in his mighty wizard magic, said "alright I'll reach in to the USART registers on the receiver with your stm32-mcp thing, twiddle the bit, and make just the TX pin of the receiver port let go"... then he did... then HE went and read the version and goodness back out, and together we proved exactly what was wrong, WHY my piggybacking idea was useful but ultimately bad, and I can go home again happy. Or yknow, frustrated. lol.

I want to use my F446RE nucleo as a flight controller, when i have it on the frame i will have to power it with 5V from an ESC, which nucleo pin i should use for that to avoid damaging the board?

I have idea to make my own fly controller so what it is?
Stm32(blackpill) with bmp3xx and mpu9250.
And make my own code to control that. People that have experience pls give your opinion how long it take?

Hello,

Im struggling to find a cheap st link programmer that'll allow me to do debugging also, like the real thing.

And not to fight with crap drivers or unrecognised stuff.......

Any1 has experience and a model to peopose ?

.tnx a lot

Btw it's for g474 and g431 stm32 series

Bungiorno,

Scrivo per chiedere un'informazione riguardo a un dubbio che mi è venuto in questi giorni. Quando creo un array con questa sintassi const array[1024] i dati vengon memorizzati nella flash dal compilatore ? e lo stesso vale anche se dopo aver creato una struct ci accedo con un puntatore ? Qualcuno sa consigliarmi un libro o un tutorial o siti web o youtube

grazie mille

Sergio

Im trying to capture a 12-1 wheel so i just tried to capture using timer2 input capture and print the period but tooth time varies widely help me im stuck in this for ever

I'm cutting it short. This project of mine is an MPPT battery charger which utilizes STM32L412RBT6P. The built in USB system is not utilized, and no backup battery is involved. The MCU is activated only when the solar panel voltage exceeds a certain threshold. So, most of the low power features are not utilized.

Also, I'd really like some tips on SW debug port design. I'm planning to snap off the module on a nucleo board of mine (F303RE) and use that to program this MCU.

I appreciate your time.