- compile issues because of missing RTC_MAGIC #defines
- missing functionality based on RTC_MAGIC in RTC based on stm32_rtcounter.c
- IRQ setup from up_rtc_initialize was later reset in up_irqinitialize
- write access to backup registers without enabling access to backup domain
- possible races in set/cancel alarm
tested with STM32F103C8 only
device now wakes up from forced STANDBY mode by alarm
reload = timclk / info->frequency;
which I belive to be incorrect, it should be
reload = timclk / info->frequency - 1;
since starting to count from 0, if I want to output half of the TIM clock, I must count to 1 and not to 2.
Surely enough, the original code did output 140/3=47 MHz, while this correction does allow the output up to 70 MHz.
I am not sure this affects most users generating slow PWM (e.g. PX4) but for frequencies
close to the PCLK, indeed the difference becomes significant.
Removed the notion of attached. The khci_usbattach is call early in
the init either in board_initalize or in board_app_initalize. In
either case it is always done prior to the the class register.
Therefore the khci_usbattach call only set a flag, and that
flag is only tested in the class register. The class register will
enable the soft connect pull up.
This fixes a bug were a SoC does not have a clockdivN register
and passes a 0 for the init value. This prevents overflow of
the 0 decremented to -1 (0xffffffff) spilling over to other
clockdivN feilds.
Remove magic numbers from code, documented the use of
undocumented bits.
Remove comments and code that were not appropriate for this
hardware.
Removed ifdef that's that were always compiled and removed code
blocks that were never compiled.
Ensure proper access order to hardware.
Per the reference manual: disable endpoints prior to configuring buffer
descriptor, then enable endpoints
Reorganize interrupt processing order to offload data after processing
errors.
Reorganize initialization so that there is a clear initialization phase,
reset phase for both the hardware and software structures.
By breaking the initialization into smaller pieces, the reset interrupt
only resets the resources within the controller that should be reset.
Rework suspend and resume logic so they perform properly
Made attach and detach functions optional. As they do not make sense for
a bus powered device.
Ensured the calls to up_usbinitalize up_usbuninitalize do not violate the
USB spec.
The hardware reset state of the the MPU precludes any bus
masters other then DMA access to memory. Unfortunately
USB and SDHC have there own DMA and will not have access to
memory in the default reset state.
This change disabled the MPU if present on system startup.
Trivially triggered with two or more threads write to regular syslog stream and to emergency stream. In this case, freeze happens because of mismatch of priv->ie (TXEIE == 0) and actually enabled interrupts in USART registers (TXEIE == 1), which leads to unhandled TXE interrupt
and causes interrupt storm for USART.
The reason was that the code hit the line "canerr("ERROR: No available mailbox\n");" in stm32_cansend, so can_xmit thinks it has sent the packet to the hardware, but actually has not. Therefore the transmit interrupt never happens which would call can_txdone, and so the size of the FIFO size does not decrease.
The reason why the code actually hit the mentioned line above, is because stm32can_txready uses a different (incomplete) condition than stm32can_send to determine if the mailbox can be used for sending, and thus can_xmit forwards the packet to stm32can_send. stm32can_txready considered mailboxes OK for sending if the mailbox was empty, but did not consider that mailboxes may not yet be used if the request completed bit is set - stm32can_txinterrupt has to process these mailboxes first.
Note that I have also modified stm32can_txinterrupt - I removed the if condition, because the CAN controller retries to send the packet until it succeeds. Also if the condition would not evaluate to true, can_txdone would not be called and the FIFO size would not decrease also.
