Search found 11 matches
- Wed Jul 26, 2017 10:52 am
- Forum: Bug Reports
- Topic: Plans on merging the latest FatFS updates?
- Replies: 14
- Views: 12995
Re: Plans on merging the latest FatFS updates?
FYI, issue raised in previous post has not been fixed in current 17.6.x branch. FatFS archive still contains ffconf.h, which overrides/breaks user-defined configuration.
- Fri Jul 21, 2017 11:26 am
- Forum: ChibiOS/HAL
- Topic: MMC (eMMC) support
- Replies: 34
- Views: 28045
Re: MMC (eMMC) support
Where did this code go? halconf.h says "MMC support is not yet implemented" but I see that barthess spent a fair amount of time working on this.
- Fri Jul 21, 2017 9:32 am
- Forum: Bug Reports
- Topic: Restarting an I2S transfer changes alignement in DMA RX buffer
- Replies: 19
- Views: 17322
Re: Restarting an I2S transfer changes alignement in DMA RX buffer
As a workaround, I found that not stopping the I2S driver between stop() and start() fixes the issue. I'll just stop and start the exchange instead as of now.
- Fri Jul 21, 2017 8:39 am
- Forum: Bug Reports
- Topic: Restarting an I2S transfer changes alignement in DMA RX buffer
- Replies: 19
- Views: 17322
Re: Restarting an I2S transfer changes alignement in DMA RX buffer
Thanks for your answer. The microphone is getting a power reset before it's re-enabled, hence my hypothesis that it might be linked to the driver/the DMA, but it is hard to investigate.
The SPI SR register is 0 before restarting the I2S so everything looks good, yet the buffer begins with the least ...
The SPI SR register is 0 before restarting the I2S so everything looks good, yet the buffer begins with the least ...
- Thu Jul 20, 2017 5:00 pm
- Forum: Bug Reports
- Topic: Restarting an I2S transfer changes alignement in DMA RX buffer
- Replies: 19
- Views: 17322
Restarting an I2S transfer changes alignement in DMA RX buffer
Hello,
I am getting data from a 24 bits I2S microphone on an STM32F417. As per the reference manual, I2S DMA access is done in half words.
Therefore, when I iterate over the RX buffer, i2s_rx_buf[0] is 0x8EAA and i2s_rx_buf[1] is 0x33XX if the microphone sent the word 0x8EAA33. So far so good ...
I am getting data from a 24 bits I2S microphone on an STM32F417. As per the reference manual, I2S DMA access is done in half words.
Therefore, when I iterate over the RX buffer, i2s_rx_buf[0] is 0x8EAA and i2s_rx_buf[1] is 0x33XX if the microphone sent the word 0x8EAA33. So far so good ...
- Tue May 30, 2017 12:40 pm
- Forum: Bug Reports
- Topic: Assertion error in I2C interrupt (thread not suspended)
- Replies: 4
- Views: 5856
Re: Assertion error in I2C interrupt (thread not suspended)
Turned out to be an undetected stack overflow. Sorry about that.
- Wed May 24, 2017 6:44 pm
- Forum: Bug Reports
- Topic: Assertion error in I2C interrupt (thread not suspended)
- Replies: 4
- Views: 5856
Re: Assertion error in I2C interrupt (thread not suspended)
There's no other task using I2C and this spurious interrupt comes after my call to the transmit function so I suspect this is the intended interrupt (especially since the rx buffer contains the data I am expecting), that's why I thought it might come from a misuse of the API.
If that does not ring a ...
If that does not ring a ...
- Wed May 24, 2017 4:07 pm
- Forum: Bug Reports
- Topic: Assertion error in I2C interrupt (thread not suspended)
- Replies: 4
- Views: 5856
Assertion error in I2C interrupt (thread not suspended)
Hi,
I am running an STM32F417.
When I start an I2C3 transfer using i2cMasterTransmitTimeout(), I encounter the following assertion error (chthreads.c:571), called by the _i2c_wakeup_isr from the I2C interrupt "i2c_lld_serve_event_interrupt" (I2Cv1/i2c_lld.c:322):
chDbgAssert(tp->p_state == CH ...
I am running an STM32F417.
When I start an I2C3 transfer using i2cMasterTransmitTimeout(), I encounter the following assertion error (chthreads.c:571), called by the _i2c_wakeup_isr from the I2C interrupt "i2c_lld_serve_event_interrupt" (I2Cv1/i2c_lld.c:322):
chDbgAssert(tp->p_state == CH ...
- Tue May 02, 2017 9:52 pm
- Forum: Bug Reports
- Topic: Wrong PLLVCO min for STM32F415/17?
- Replies: 5
- Views: 6699
Re: Wrong PLLVCO min for STM32F415/17?
Hi RM,
Sorry for the late answer. You're talking about line 179, I'm talking about line 219.
I believe it is for this MCU (and it does fix the problem at compilation time):
#if defined(STM32F40_41xxx) || defined(__DOXYGEN__)
Here is the patch:
diff --git a/os/hal/ports/STM32/STM32F4xx/hal_lld ...
Sorry for the late answer. You're talking about line 179, I'm talking about line 219.
I believe it is for this MCU (and it does fix the problem at compilation time):
#if defined(STM32F40_41xxx) || defined(__DOXYGEN__)
Here is the patch:
diff --git a/os/hal/ports/STM32/STM32F4xx/hal_lld ...
- Tue Apr 18, 2017 10:49 pm
- Forum: Bug Reports
- Topic: Wrong PLLVCO min for STM32F415/17?
- Replies: 5
- Views: 6699
Wrong PLLVCO min for STM32F415/17?
Hi,
hal/ports/STM32/STM32F4xx/hal_lld.h defines the following:
#define STM32_PLLVCO_MIN 192000000
And performs following check:
#if ((STM32_PLLI2SN_VALUE >= 192) && (STM32_PLLI2SN_VALUE <= 432)) ...
...
#else
#error
#endif
However, reference manual page 205 says that ...
hal/ports/STM32/STM32F4xx/hal_lld.h defines the following:
#define STM32_PLLVCO_MIN 192000000
And performs following check:
#if ((STM32_PLLI2SN_VALUE >= 192) && (STM32_PLLI2SN_VALUE <= 432)) ...
...
#else
#error
#endif
However, reference manual page 205 says that ...