1. Update to handle 12-bit resolution
2. Properly handle the pin configuration
3. Update the pin setup to handle the ADC B channel
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
Thus far the default position has been after the application plus two
spare sectors. For simplicity and to have a predictable location for the
TDBStore with the default configuration the location is now switched to
the end of the flash. Two last sectors to be exact.
On Nuvoton targets, lp_ticker_set_interrupt(...) needs around 3 lp-ticker
ticks to take effect. It may miss when current tick and match tick are very
close (see hal/LowPowerTickerWrapper.cpp). Enlarge LPTICKER_DELAY_TICKS to
4 from 3 to address this boundary case.
This test requires total latency (tot = h/w + s/w) (wakeup from deepsleep) be
under 1ms. To check the issue, measure total latency on Nuvoton targets:
TARGET EXP(us) EXP+TOL(us) ACT(us)
NANO130 42000 43000 42939
NUC472 42000 43000 42236
M453 42000 43000 43274
M487 42000 43000 42877
M2351 42000 43000 43213
Checking h/w spec, h/w latency (wakeup time from normal power-down mode) on
M487/M2351 is just 1us (n/a on other targets). S/W latency plays the major
part here.
S/W latency relies on system performance. On Nuvoton targets, 'LPTICKER_DELAY_TICKS'
possibly complicates the test. Anyway, to pass the test, add extra 1ms latency
(deep-sleep-latency) in targets.json for Nuvoton targets.
Macro which restricted compilation to GCC_ARM is removed.
Existing read_write() test is amended to call stat() and check that correct size is returned.
This change is required by the Samsung S111(S5JS100). On this board timer clock used for us ticker operates at 26MHz.
According to current requirements, 8 MHz is the top limit for us ticker timer.
This change relaxes top limit to 100 MHz, but only for 32-bit timers.
Ticker common layer schedules one interrupt per timer rollover to trace elapsed time. We need to ensure that this operation is not performed too frequently. I.e. in case of 16-bit timer at 32 MHz, the timer rollover will happen after ~2 ms. This may cause that there will be no time for other tasks. That is why we increase the top limit, but only for 32-bit timers.
When STM32F746-DISCO board was being used in (unsupported) USBHost mode,
the communication was unreliable. Our investigation revealed that the
problem lied in redundant IN tokens that the host generated even though
it shouldn't. This could lead to endless high-frequency NAKs being
received from device, which caused watchdog reset as USBHost spent all
time in interrupt handlers.
In our application the clocks frequencies are:
* HCLK = 48 MHz
* APB1 = 6 MHz
* APB2 = 12 MHz
We have captured the raw USB High-Speed traffic using OpenVizsla.
Without this change, when USB MSD device connected to the system
responded to IN with NAK, there were excessive IN tokens generated about
667 ns after the NAK. With this commit the IN tokens are generated no
sooner than 10 us after the NAK.
The high frequency of the IN/NAK pairs is not the biggest problem.
The biggest problem is that the USB Host did continue to send the IN token
after DATA and ACK packets were received from device - *without* any request
from upper layer (USB MSD).
The USB MSD devices won't have extra data available on Bulk IN endpoint
after the expected data was received by Host. In such case IN/NAK cycle
time is only houndreds of nanoseconds, the MCU has no time for anything else.
The problem manifested not only on Bulk endpoints, but also during
Control transfers. Example correct scenario (when this fix is applied):
* SETUP stage
* SETUP [host -> address 0 endpoint 0]
* DATA0 [80 06 00 01 00 00 08 00] [CRC16: EB 94]
* ACK
* DATA stage
* IN
* NAK
... the IN/NAK repeated multiple time until device was ready
* IN
* DATA1 [12 01 10 02 00 00 00 40] [CRC16: 55 41]
* ACK
* STATUS stage
* OUT
* DATA1 ZLP
* ACK
Without this commit, in DATA stage, after the ACK was received, the host
did send extra IN to which device responded with STALL. On bus it was:
* DATA stage
...
* IN
* DATA1 [12 01 10 02 00 00 00 40] [CRC16: 55 41]
* IN
* STALL
* IN
* STALL
* STATUS stage
* OUT
* DATA1 ZLP
* STALL
In the fault case the next SETUP was sent only after 510 ms, which
indicates timeout in upper layer.
With this commit the next SETUP is sent 120 us after the STATUS stage ACK.
Originally, nu_delay_cycle_x4(...) is borrowed from mbed test code for delay
cycle. Currently, it is not used on Nuvoton targets. If delay cycle is needed,
use wait_ns(...) instead which has strict implementation and has passed tests.