In 1.1, NbTrans governs both unconfirmed and confirmed traffic.
We cannot set number of retries ourselves. Based upon NbTrans received
in linkADRReq command, we will retry. If NbTrans is 1, we will send only
one message and if ack is not received we will generate TX error event.
Its the NS now which controls how many retransmission a device can do
without incrementing Frame counter. When we fail with TX error after not
receiving an ack, we increment the frame counter. This is necessary as
the NS will drop anything with the previous counter and it can happen
that the NS may have sent an ack but we didn't receive it.
Rejoin requests and presence/absence of CFlist demand different
handling.
If a Rejoin request was sent we shall use RJCountX (0,1) instead of dev
nonce for key derivation.
If a Rejoin request is not of type 2, we reset mac, phy parameters
alongwith frame counters. However, if it is type 2, we reset frame
counters only.
If cflist i present, we shall always apply it as it is.
If it's not and rejoin type is not type 2, we restore default channels.
Otherwise the local channels do not change.
LoRaWAN specification 1.1.0 is incorrect in handling of FOpts encrytpion.
A CR was made by STMicroelectronics which correctly addresses the issue.
We have taken that CR and implemented in our code base.
RekeyInd Mac command was being handled incorrectly.
parse_mac_commnad_to_repeat() was missing handling for RekeyInd mac
command. Plus it is a sticky mac command as the spec says that it needs
to persist until we receive a RekeyConf mac command.
After deriving JSEncKey we were wrongly clearing the AES context.
We shouldn't clear the context until the function is done doing its job.
That was why JSINtKey derivation was wrong which would result in MIC
failures.
Although we always add a port field for Uplink traffic, the spec allows
for fport field to be excluded. So there can be network server instances
which would exclude fport field from downlinks. We are now adding
handling for such situations.
BE to LE fixes, missing MLME types added
LoRaWAN 1.1 Features added (Some LoRaPhy impl missing still + some TODOs in code)
- MLME confirm handling refactored
- Rejoin handling missing
- new CF_LIST mechanism missing (+resets involved)
- NVM handling missing
Rejoin logic added
1. Re-organize to make clear for all targets/toolchains support in single startup file
2. Inline assembly syntax is limited, esp. on IAR. Try paving the way for accessing external symbols still in inline assembly instead of re-write in assembly.
1. Enable GCC support on non-secure targets
2. Disable GCC support on secure targets becasue of GCC bug (as of 9-2019-q4-major): In non-secure entry function, callee-saved registers must be restored, but they are incorrectly cleared at optimization level "Os".
In STM32 Cube HAL, in interrupt mode (async),
2 bytes can be prepared in hardware registers without any read
(1 in regular register, the other in shift register),
but Only 1 RX byte can stored in hardware register, specially when there is no hardware FIFO.
If interrupt handling is fast enough, each read is made in parralele of the write.
But if interrupt handling is too long or is interrupted for too long,
it can happen that one read byte is lost (overrun).
For STM32F4, Tickless has been deactivated to avoid such issue.
For STM32L0, we don't want to deactivate tickless,
because those chips are specially design for lowpower.
So instead of removing SPI async mode,
we propose to change the HAL behavior specially for L0:
each byte is send only when previous read is performed.
Thus only 1 RX byte at a time which is saved in hardware register.
This prevent overrun, but it introduceS some latency between each byte send,
this is why it is not applied to all STM32 families.
Add a "used" attribute to SVCHandler_main/tfm_pendsv_do_schedule to fix ARMC6 build with
the "-flto" flag.
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST. )
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST.)
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST.)
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST.)
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST.)
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST. )
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.
Add a "used" attribute to __vector_handlers to fix ARMC6 build with
the "-flto" flag.
(Error: L6236E: No section matches selector - no section to be FIRST/LAST. )
This attribute, attached to a function/variable, means that code must be emitted
for the function even if it appears that the function is not referenced.