STM32L4 Core

Cores are the underlying magic that make the Arduino API possible
umejopa
Posts: 9
Joined: Sat Dec 05, 2015 4:53 am

Re: STM32L4 Core

Post by umejopa » Fri May 05, 2017 5:39 am

Thanks will try to change the A/D setting.
My DFU problem may can be that the bluepill hardware are diffrent. I did only get the ST Dfu dected by the computer so went to ST-link.
Dont get usbserial to work but i think that is only computer problem as serial1 work over Fdi adaptern.
It is some usb driver thats are missing or wrong.

Jonas

User avatar
GrumpyOldPizza
Posts: 184
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Sun May 07, 2017 12:13 am

umejopa wrote:Thanks will try to change the A/D setting.
My DFU problem may can be that the bluepill hardware are diffrent. I did only get the ST Dfu dected by the computer so went to ST-link.
Dont get usbserial to work but i think that is only computer problem as serial1 work over Fdi adaptern.
It is some usb driver thats are missing or wrong.

Jonas
I am assuming you are on Windows. Did you install the drivers like the instructions said?

gato_
Posts: 11
Joined: Mon Apr 03, 2017 10:18 am

Re: STM32L4 Core

Post by gato_ » Thu Sep 07, 2017 9:18 am

I finally decided to do a custom board based on stm32l476. After modifying the variants file, I've managed to make almost everything to work, but there has been an issue. My board is meant to be a subsystem of a bigger one. As such, it communicates through I2C, as slave. No problem arises when the master writes to the board, but there are are troubles with a Wire.requestFrom() from the master, which freezes waiting for an answer. At the beggining, I thought it might be because of different processors communicating through I2C, but then I made two of the stm32 boards, and reduced the incidence to the failure of the following sketch:
MASTER

Code: Select all

#include <Wire.h>
void setup() {
  Wire.begin();        // join i2c bus (address optional for master)
  Serial.begin(9600);  // start serial for output
}

void loop() {
  Serial.println("\n a: ");
  Wire.requestFrom(3, 1);  
    //while (!Wire.available()){;}
    uint8_t c = Wire.read(); 
    Serial.print(c,HEX);        
    //}
  delay(500);
}
SLAVE

Code: Select all

#include <Wire.h>

void setup() {
  Wire.begin(3);  
  Wire.onRequest(requestEvent); 
}

void loop() {
  delay(100);
}

void requestEvent() {
  Wire.write(0x48); 
}
The slave appers to be sending a 0 always. I checked that with a logic analyzer
Image

I tried several things. The requestEvent function does seem to be executing (trying putting some print function there). I tried several data format, but the result is always the same. Something doesn't seem to be triggering...

gato_
Posts: 11
Joined: Mon Apr 03, 2017 10:18 am

Re: STM32L4 Core

Post by gato_ » Thu Sep 07, 2017 11:24 am

ok. Traced it back to function TwoWire::write(), line 175 of Wire.cpp:

Code: Select all

size_t TwoWire::write(uint8_t data)
{
   /* if (!_tx_active) {
	return 0;
    }
*/
    if (_tx_write >= BUFFER_LENGTH) {
	return 0;
    }

    _tx_data[_tx_write++] = data;

    return 1;
}
with that lines commented, it does react. So the question is, why doesn't onRequest() triggers _tx_active?

User avatar
GrumpyOldPizza
Posts: 184
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Fri Sep 08, 2017 12:15 pm

gato_ wrote:
Thu Sep 07, 2017 11:24 am
ok. Traced it back to function TwoWire::write(), line 175 of Wire.cpp:

Code: Select all

size_t TwoWire::write(uint8_t data)
{
   /* if (!_tx_active) {
	return 0;
    }
*/
    if (_tx_write >= BUFFER_LENGTH) {
	return 0;
    }

    _tx_data[_tx_write++] = data;

    return 1;
}
with that lines commented, it does react. So the question is, why doesn't onRequest() triggers _tx_active?
Good question. Clearly a bug. I am wondering how to fix that. In theory if you are a slave, you could prebuffer data, right ? So wouldn't you want to be able to write data before are after the first onRequest() till the whole transmission is over (STOP or START_REPEAT conditions) ...

User avatar
GrumpyOldPizza
Posts: 184
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Fri Sep 08, 2017 12:17 pm

gato_ wrote:
Thu Sep 07, 2017 9:18 am

The slave appers to be sending a 0 always. I checked that with a logic analyzer
Image
That is the 2nd bug. The I2S SLAVE should send back a NACK rather than to send dummy data.

gato_
Posts: 11
Joined: Mon Apr 03, 2017 10:18 am

Re: STM32L4 Core

Post by gato_ » Fri Sep 08, 2017 1:28 pm

There is more. Commenting that line just fixed the 1 byte example. On trying to send several, it freezes again....
Ok. I think I will take a look on the I2c implementation

User avatar
GrumpyOldPizza
Posts: 184
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Fri Sep 08, 2017 2:09 pm

gato_ wrote:
Fri Sep 08, 2017 1:28 pm
There is more. Commenting that line just fixed the 1 byte example. On trying to send several, it freezes again....
Ok. I think I will take a look on the I2c implementation
Looks like I busted the logic somewhere along the line. The onRequest() needs to also reset the tx buffer ...

User avatar
GrumpyOldPizza
Posts: 184
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: STM32L4 Core

Post by GrumpyOldPizza » Sat Sep 16, 2017 1:21 pm

GrumpyOldPizza wrote:
Fri Sep 08, 2017 2:09 pm
gato_ wrote:
Fri Sep 08, 2017 1:28 pm
There is more. Commenting that line just fixed the 1 byte example. On trying to send several, it freezes again....
Ok. I think I will take a look on the I2c implementation
Looks like I busted the logic somewhere along the line. The onRequest() needs to also reset the tx buffer ...
I need to rework some of the Wire.cpp code for slave mode to be compatible with Arduino Zero. Half way that is.

On a onRequest() the Arduino Zero core assumes you fill up the buffer with data, ONCE. If the master requests more data than is preset Arduino Zero sends 0xff bytes. Arduino AVR sends a proper NACK. Again, there is no refill of the TX buffer. Arduino Zero has a 64 byte sized ringbuffer class, Arduino AVR as 32 byte buffer. The corresponding _tx_active logic is active while the whole slave TX is going on. Hence it's possible to add bytes in theory during whole transmission (plus a ton of race conditions). The Arduino AVR code assumes that you write all the data subsequent to a onRequest() callback. They do this inline without buffer, and hence block the ISR. Thus in this core, it's not possible to write outside the onRequest() callback.

The onReceive() is somewhat more tricky it seems. Arduino AVR actually has a intermediate buffer where it reads data into, and only upon completion of this operation, data is copied into the RX buffer. That means you can read data a tad longer. Arduino Zero simply nukes the old buffer ... Teensy for KINETIS follows the same logic as Arduino Zero ...

For STM32L4 the attempt was made the allow segmented transmit/receive. Guess I need to change that to the Arduino Zero model, to be one-shot, and NACK on buffer underflow/overflow.

gato_
Posts: 11
Joined: Mon Apr 03, 2017 10:18 am

Re: STM32L4 Core

Post by gato_ » Tue Sep 19, 2017 9:57 am

Actually, the onReceive() call doesn't seem to have any problems. And I am having some doubts about what happens with the onRequest() one. Are you using any environment to check the registers? if so, which one? what pins are employed for debugging? Thank you. Otherwise, the core is great

Post Reply