Needed for hcan->TxState to reset. In some cases when the host reboots, the TxState get locked forever and there's no way to recover other than resetting the controller.
After the host reboots, the USBD_GS_CAN_Start function is called, In that
we take a pointer out of frame pool and never pushes it back, So every
time the host reboot, we leak a pointer one by one
The documents a workaround for a NXP chip errata on LPC546xx
controllers (Errata sheet LPC546xx / USB.15).
According to the document corruption can occur when the following
conditions are met:
* A TX (IN) transfer happens after a RX (OUT) transfer.
* The RX (OUT) transfer length is 4 + N * 16 (N >= 0) bytes.
Even though the struct gs_host_frame has a size of 76 bytes for a FD
frame, which does not apply to the above rule, corruption could be
seen.
Adding a dummy byte to break the second condition also on transfer
lengths with 4 + N * 8 bytes reliably circumvents USB transfer data
corruption.
The firmware can now request this quirk by setting
GS_CAN_FEATURE_REQ_USB_QUIRK_LPC546XX.
The CANtact FD and other devices implement a gs-usb compatible USB
protocol. The protocol has been extended to support CAN-FD and the
changes on the Linux gs_usb driver will be mainlined soon.
This patch adds the new GS_CAN_MODE_*, GS_CAN_FEATURE_*,
GS_USB_BREQ_DATA_BITTIMING, and GS_CAN_FLAG_* bits as well as struct
gs_host_frame_canfd to the candlelight driver.
This is mainly for documentation purpose, as the STM32F042 and
STM32F072 don't support CAN-FD. But there are some ports to CAN-FD
capable STM32 µC that can make use of these definitions.
[1] https://github.com/linklayer/gs_usb_fd/issues/2
The bits in GS_CAN_MODE_ correspond to the bits in GS_CAN_FEATURE_*.
This means the bits 5 and 6 of GS_CAN_MODE_ are not "free", document
this by adding a comment to the corresponding GS_CAN_FEATURE_*.
32-bit milliseconds gives a 49.7-day wrap period which would break the
blinking patterns.
Fix GH #78, and hopefully makes the code cleaner / less error-prone.
Currently the sequence is specified with a uint8 but we still clamp
deltas to INT32_MAX in case the tick resolution ever changes.
Clamping the interval to INT32_MAX should ensure that for the
next (UINT32_MAX - 1) ticks, the macro SEQ_ISPASSED(now, wait_until)
produces the correct logic. Example :
now = 0
delta = INT32_MAX (7FFF....)
wait_until = now + delta = INT32_MAX (7FFF...
// 0 ticks later
(now - wait_until) == -7FFF FFFF ; SEQ_ISPASSED = false
// 1 tick later
(new_now - wait_until) == -7FFF FFFE ; SEQ_ISPASSED = false
// 7FFF... ticks later
(new_now - wait_until) == 0; ok, now SEQ_ISPASSED is true
// new_now == UINT32_MAX - 1 == FFFF FFFE, almost rollover
(new_now - wait_until) == 7FFF FFFF ; ok, SEQ_ISPASSED is still true
// new_now == UINT32_MAX == FFFF FFFF,
(new_now - wait_until) == 8000 0000 == -7FFF FFFF; this fails because
the sign changed !
Also remove some useless math/DSP headers.
The USB code really needed updating, considering the following entries from ST's
release notes (
https://raw.github.com/STMicroelectronics/STM32CubeF0/master/Release_Notes.html
) :
-Bug fix: USB_ReadPMA() and USB_WritePMA() by ensuring 16-bits access to
USB PMA memory
-Bug fix: correct USB RX count calculation
-Fix USB Bulk transfer double buffer mode
Avoid using <assert.h> because the standard assert() pulls in
fprintf and its of dependencies, as well as including __FILE__:__LINE__
strings for each assert() call. All this has an unacceptable memory
cost, as well as being useless since there is nothing to printf *to*.
Currently assert_basic() was added to check calloc() return values;
in case of failure we simply halt the core with BKPT(0). This could be
improved and refined.
This had probably been accidentally reverted in
2ebc665109887bfe95a4ad63ebe5e1d7d13c0fef ? flash_data_rom ended up on the same flash page as other unrelated data, which meant flash_flush() would've erased too much.
Also reduce nvm area to 1k and use variables to calculate area. (F042
devices only have 1kB pages vs 2k for the F072)
