Serial Problem

[3s1d]

Hi, I am using your code as a base to get our module running. If you want, you can reimport our definitions. We'll sell it as a module including a LoRa interface once it's ready... https://github.com/3s1d/arduino-STM32L4

I have a problem regarding the serial port. If I am doing: Serial1.println("lala") then it boils down to: Serial.print("lala") + Serial.println() The last call always will fail because this call in write() is true: if (_uart->state != UART_STATE_READY) As an quick work around (and because I don't understand your code fully) I quickly come up with that workaround: https://github.com/3s1d/arduino-STM32L4/commit/4f42d62123788df102bff0fde4237ff0ddfdff3d#diff-82edf5670bbf6621faddb536b80d6cbf But there must be a better solution to it.

Secondly: Can I enable the TX DMA Mode on my variant.cpp https://github.com/3s1d/arduino-STM32L4/commit/4f42d62123788df102bff0fde4237ff0ddfdff3d#diff-96ee7d0ff43e5f3994ab4332f8e15380 It works, but not sure whether this has an effect on the system at all or if I am using some otherwise occupied hardware?

Many thanks in advance! Juergen

[GrumpyOldPizza]

I don't think there is a problem.

Serial (CDC.cpp / Uart.cpp) use internally a buffer. So Serial.print()/Serial.println() -> Serial.write() will simply fill the buffer, and then this one is drained asynchronously in the background. If called from "loop()" and the buffer is full, the code will wait. If called from and ISR, the code will not wait, and Serial.write() will simply return the number of bytes it was able to write.

In none of the case it should ever hit "if (_uart->state != UART_STATE_READY)". There is a code-path for async writes with a callback that would hit that of course, but your description does not indicate that this is what you are doing.

With regards to DMA. In the current system code model, DMA are statically assigned. You can see the mapping in stm32l4_wiring_private.h. USART2_TX conflicts with I2C1_RX on DMA1_CH7. I suppose one could move I2C1_RX to DMA2_CH6 though, because for STM32L432 only SAI1B is in use (add I2C _MODE_RX_DMA_SECONDARY).

• Thomas

On Mon, Apr 10, 2017 at 5:49 AM, Juergen Eckert notifications@github.com wrote:

Hi, I am using your code as a base to get our module running. If you want, you can reimport our definitions. We'll sell it as a module including a LoRa interface once it's ready... https://github.com/3s1d/arduino-STM32L4

I have a problem regarding the serial port. If I am doing: Serial1.println("lala") then it boils down to: Serial.print("lala") + Serial.println() The last call always will fail because this call in write() is true: if (_uart->state != UART_STATE_READY) As an quick work around (and because I don't understand your code fully) I quickly come up with that workaround: 3s1d/arduino-STM32L4@4f42d62#diff-82edf5670bbf6621faddb536b80d6cbf https://github.com/3s1d/arduino-STM32L4/commit/4f42d62123788df102bff0fde4237ff0ddfdff3d#diff-82edf5670bbf6621faddb536b80d6cbf But there must be a better solution to it.

Secondly: Can I enable the TX DMA Mode on my variant.cpp 3s1d/arduino-STM32L4@4f42d62#diff-96ee7d0ff43e5f3994ab4332f8e15380 https://github.com/3s1d/arduino-STM32L4/commit/4f42d62123788df102bff0fde4237ff0ddfdff3d#diff-96ee7d0ff43e5f3994ab4332f8e15380 It works, but not sure whether this has an effect on the system at all or if I am using some otherwise occupied hardware?

Many thanks in advance! Juergen

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/10, or mute the thread https://github.com/notifications/unsubscribe-auth/AG4QfDrCDJ7_10TGPFdHKke6DfjIgbIdks5ruhdQgaJpZM4M4rJ9 .

[3s1d]

Hi Thomas,

thank you for your fast response. Might it be an issue with my custom variant.cpp? (Link see above).

Right now I am using:

extern const stm32l4_uart_pins_t g_Serial1Pins = { GPIO_PIN_PA3_USART2_RX, GPIO_PIN_PA2_USART2_TX, GPIO_PIN_NONE, GPIO_PIN_NONE };
extern const unsigned int g_Serial1Instance = UART_INSTANCE_USART2;
extern const unsigned int g_Serial1Mode = UART_MODE_RX_DMA | UART_MODE_TX_DMA;

extern const stm32l4_i2c_pins_t g_WirePins = { GPIO_PIN_PB6_I2C1_SCL, GPIO_PIN_PB7_I2C1_SDA };
extern const unsigned int g_WireInstance = I2C_INSTANCE_I2C1;
extern const unsigned int g_WireMode = I2C_MODE_RX_DMA_SECONDARY;

I am doing in the loop(): Serial.println(millis()); (USB CDC) works as supposed. But Serial1.println(millis()); misses the newline as long as I do not put the following lines into write() (UART.cpp): if (_uart->state != UART_STATE_READY) flush();

Something keeps the state machine busy and not accepting any more bytes before the internal buffer is not fully depleted. (The newline w/o workaround only appears when I add: delay(100); Serial1.println(); which effectively waits until the buffer is emptied.) Not sure why...

Thanks Juergen

[GrumpyOldPizza]

My bad. I goofed. With some USB rework a bad unintended Uart.cpp change made it into the source. Fixed as of a few minutes ago.

BTW, a few recommendations from looking at your github:

(1) Please populate OSC32. The code to drive STM32L432 without LSE is not well tested, and crystal-less USB has not been implemented at all. RTC via LSI is also not tested (however (2) might be a cheaper alternative).

(2) You may want to connect the 32MHz output of SX1272 (DIO5) to PA0 (see 5.3.2 of the SX1272 datasheet). That may allow in the future the 32MHz input clock to be used directly, unless SX1272 is in sleep mode. You got PA0 unassigned so that is probably a trivial routing change. That would allow calibration of LSI for RTC, and perhaps a code path similar to STM32L476 to use HSE to generate the 48MHz for USB via the PLL rather than HSI48. All of this is untested, but since you go the GPIO left over on STM32L432 it's a good insurance policy.

(3) Please connect DIO1/DIO2/DIO3 to STM32L432 (you seem to have enough pins left over). A future release of the STM32L4 core may include support for SX1272/SX1276 directly, but will require DIO1/DIO2/DIO3.

• Thomas

On Mon, Apr 10, 2017 at 6:51 AM, Juergen Eckert notifications@github.com wrote:

Hi Thomas,

thank you for your fast response. Might it be an issue with my custom variant.cpp? (Link see above).

Right now I am using:

extern const stm32l4_uart_pins_t g_Serial1Pins = { GPIO_PIN_PA3_USART2_RX, GPIO_PIN_PA2_USART2_TX, GPIO_PIN_NONE, GPIO_PIN_NONE }; extern const unsigned int g_Serial1Instance = UART_INSTANCE_USART2; extern const unsigned int g_Serial1Mode = UART_MODE_RX_DMA | UART_MODE_TX_DMA;

extern const stm32l4_i2c_pins_t g_WirePins = { GPIO_PIN_PB6_I2C1_SCL, GPIO_PIN_PB7_I2C1_SDA }; extern const unsigned int g_WireInstance = I2C_INSTANCE_I2C1; extern const unsigned int g_WireMode = I2C_MODE_RX_DMA_SECONDARY;

I am doing in the loop(): Serial.println(millis()); (USB CDC) works as supposed. But Serial1.println(millis()); misses the newline as long as I do not put the following lines into write() (UART.cpp): if (_uart->state != UART_STATE_READY) flush();

Something keeps the state machine busy and not accepting any more bytes before the internal buffer is not fully depleted. (The newline w/o workaround only appears when I add: delay(100); Serial1.println(); which effectively waits until the buffer is emptied.) Not sure why...

Thanks Juergen

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/10#issuecomment-292939875, or mute the thread https://github.com/notifications/unsubscribe-auth/AG4QfGPTHde_UBLPLHJXv4xSZ5b2OKuKks5ruiW2gaJpZM4M4rJ9 .

[3s1d]

Hi Thomas,

I can confirm it working! Thanks.

Regarding your recommendations:

(1) I'd love to add an crystal, however I'm simply not having enough space for it. It's a very small module (15x23mm) which exposes 12 pins: SWD, USB, I2C, UART, Analog (all in parallel). This plus a SX1272 under a RF shield and the whole place is occupied...

I had a quick play with USB and it seems to work perfectly (for 24Mhz). Even the USB flasher does not require a crystal. So without having every had a deep look into the datasheet I'd say it works perfectly without. So far I haven't tested the RTC, but for our propose precision should be good enough. We plan to have a PPS from GPS and/or additionally sync every 24h over the mobile network.

(2) DIO5 -> PA0 would be possible but would require me routing a 32Mhz signal across the whole PCB. Right now, I am preparing the PCB for EMI testing (ETSI) and this signal would set me back at least 4 weeks...

(3) Same for DIO1-3. All those signals can easily be checked by polling. Sorry the PCB is already a bit too far into production.

In case you are interested in a SX1272 driver take a look at my 'fanet' repository. :)

Cheers, Juergen

[GrumpyOldPizza]

Oki. Just to reiterate, USB without LSE will not work properly, as there is no code support for crystal-less USB as of right now, nor is there support planned.

• Thomas

On Mon, Apr 10, 2017 at 9:47 AM, Juergen Eckert notifications@github.com wrote:

Hi Thomas,

I can confirm it working! Thanks.

Regarding your recommendations:

(1) I'd love to add an crystal, however I'm simply not having enough space for it. It's a very small module (15x23mm) which exposes 12 pins: SWD, USB, I2C, UART, Analog (all in parallel). This plus a SX1272 under a RF shield and the whole place is occupied...

I had a quick play with USB and it seems to work perfectly (for 24Mhz). Even the USB flasher does not require a crystal. So without having every had a deep look into the datasheet I'd say it works perfectly without. So far I haven't tested the RTC, but for our propose precision should be good enough. We plan to have a PPS from GPS and/or additionally sync every 24h over the mobile network.

(2) DIO5 -> PA0 would be possible but would require me routing a 32Mhz signal across the whole PCB. Right now, I am preparing the PCB for EMI testing (ETSI) and this signal would set me back at least 4 weeks...

(3) Same for DIO1-3. All those signals can easily be checked by polling. Sorry the PCB is already a bit too far into production.

In case you are interested in a SX1272 driver take a look at my 'fanet' repository. :)

Cheers, Juergen

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/10#issuecomment-292990942, or mute the thread https://github.com/notifications/unsubscribe-auth/AG4QfApvco6VCKHdZdmz5359mjOlpcWmks5ruk8fgaJpZM4M4rJ9 .

[kriswiner]

Is anything these guys are doing going to make it easier for you to support Grasshopper or the L4 family?

On Mon, Apr 10, 2017 at 9:25 AM, Thomas Roell notifications@github.com wrote:

Oki. Just to reiterate, USB without LSE will not work properly, as there is no code support for crystal-less USB as of right now, nor is there support planned.

• Thomas

On Mon, Apr 10, 2017 at 9:47 AM, Juergen Eckert notifications@github.com wrote:

Hi Thomas,

I can confirm it working! Thanks.

Regarding your recommendations:

(1) I'd love to add an crystal, however I'm simply not having enough space for it. It's a very small module (15x23mm) which exposes 12 pins: SWD, USB, I2C, UART, Analog (all in parallel). This plus a SX1272 under a RF shield and the whole place is occupied...

I had a quick play with USB and it seems to work perfectly (for 24Mhz). Even the USB flasher does not require a crystal. So without having every had a deep look into the datasheet I'd say it works perfectly without. So far I haven't tested the RTC, but for our propose precision should be good enough. We plan to have a PPS from GPS and/or additionally sync every 24h over the mobile network.

(2) DIO5 -> PA0 would be possible but would require me routing a 32Mhz signal across the whole PCB. Right now, I am preparing the PCB for EMI testing (ETSI) and this signal would set me back at least 4 weeks...

(3) Same for DIO1-3. All those signals can easily be checked by polling. Sorry the PCB is already a bit too far into production.

In case you are interested in a SX1272 driver take a look at my 'fanet' repository. :)

Cheers, Juergen

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/10# issuecomment-292990942, or mute the thread https://github.com/notifications/unsubscribe-auth/ AG4QfApvco6VCKHdZdmz5359mjOlpcWmks5ruk8fgaJpZM4M4rJ9 .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/10#issuecomment-293002620, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqO-VYptdO8NUYRFO81ttsMbDRENks5rulfmgaJpZM4M4rJ9 .

[3s1d]

Hi kris,

not sure what you mean by that? Just tried to point out a bug in the code here.

@Thomas: Now you got me a little worried. USB is an optional feature for our module, also I am using it right now for code upload and CDC. W/o any issue what so ever. It seems to run perfectly w/o crystal. Our daily driver will be UART, SPI and I2C, which should run perfectly anyway?! Found those slides: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjxuejGsZrTAhVIWBQKHZJbAMcQFggcMAA&url=http%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Fproduct_training%2Fstm32l4_peripheral_usb.pdf&usg=AFQjCNHUUOu6tDj2MuAXC29a9ahTrrRIqQ&sig2=f0GIov1fyeC2ZwexwftRgQ&cad=rja which advertise a XTAL-less full speed USB due to a CRS which corrects the HSI RC. Which means everything should be fine? Right? Please say so :)

Cheers, Juergen

[GrumpyOldPizza]

Juergen,

Kris was commenting on a project of ours, which is a LoRaWAN setup. Your project has no bearing on that. For LoRaWAN and low power we need DIO0/DIO1/DIO2. DIO0 only with polling is not an option. Same goes with the missing OSC32. Maybe not a problem for you, but a biggy for us. It would be possible that you can layer your protocol onto of a shared driver that we also use for LoRaWAN, but not the other way around.

With regards to USB. Yes, the chip supports crystal-less USB, and yes the STM32 BOOTLOADER supports it. But the Arduino code does not. It assumes the presence of the 32768Hz LSE and locks HSI48 via CRS to LSE (same with MSI). There is no code implemented that would link CRS with HSI48 on USB SOF (which is crystal-less USB). It's non-trivial to do and has to fit into the framework. The hardware platforms we support do all have 32768Hz, for a good reasons, so there is no good incentive to add this kind of support, which would come at great cost, testing time wise. That's why I suggested as a quick and dirty WAR to hook up DIO5 to PA0, which gives a direct 32MHz HSE. This way the 48MHz can be derived directly via PLL, rather than via the fragile CRS mechanism.

• Thomas

On Mon, Apr 10, 2017 at 11:26 AM, Juergen Eckert notifications@github.com wrote:

Hi kris,

not sure what you mean by that? Just tried to point out a bug in the code here.

@Thomas https://github.com/Thomas: Now you got me a little worried. USB is an optional feature for our module, also I am using it right now for code upload and CDC. W/o any issue what so ever. It seems to run perfectly w/o crystal. Our daily driver will be UART, SPI and I2C, which should run perfectly anyway?! Found those slides: https://www.google.de/url?sa= t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjxuejGsZrTAhVIWBQKHZJbA McQFggcMAA&url=http%3A%2F%2Fwww.st.com%2Fresource%2Fen% 2Fproduct_training%2Fstm32l4_peripheral_usb.pdf&usg= AFQjCNHUUOu6tDj2MuAXC29a9ahTrrRIqQ&sig2=f0GIov1fyeC2ZwexwftRgQ&cad=rja which advertise a XTAL-less full speed USB due to a CRS which corrects the HSI RC. Which means everything should be fine? Right? Please say so :)

Cheers, Juergen

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GrumpyOldPizza/arduino-STM32L4/issues/10#issuecomment-293019918, or mute the thread https://github.com/notifications/unsubscribe-auth/AG4QfLJx76VdekXDajQM0yQ3ZcwUKMNaks5rumZJgaJpZM4M4rJ9 .

[3s1d]

Thanks for being clear on that one. Once I need USB, I'll correct it and will let you know. Adding a crystal is next to impossible...

Thanks, Juergen