Initial button press wakeup of 4 seconds is sometimes inadequate to establish BT connection.
This change will expand the Initial button wakeup from 4 seconds to 8 seconds.
Device sleep behavior after will be as follows:
(Changed)
Initial Button Wakeup to Sleep : 8s
(No Change)
Subsequent Button Action to Sleep : 4s
Leaving RF Field wake to sleep : 3s
BLE Disconnect to sleep : 4s
USB Power Disconnect to sleep : 3s
Example behavior :
User wakes device with Button B (8 Sec to sleep)
User pushes button B again (Now 4 Sec to sleep)
User Places device in RF field (Maintain wake)
User removes device from RF field (3 sec to sleep)
If user discontinues the user journey at any point, the identified condition will invoke sleep at defined times.
Disruptive changes:
- tag types are 2-byte long with new values
- GET_SLOT_INFO returns 32 bytes as tag types are now 2-byte long
- "enable" is not common to one slot anymore but bound to the HF or LF part
- GET_ENABLED_SLOTS returns 16 bytes as we get "enabled_hf" and "enabled_lf" for each slot
- SET_SLOT_ENABLE needs 3 bytes slot_number|sense_type|enable as we need to specify to enable HF or LF
- slotConfig changed a lot but this is internal to the fw and its flash and a function does the format conversion on first boot after flash
so slot data is preserved on fw upgrade, but if one downgrades to a previous version, data will be erased.
This huge commit tries to enhance several things related to the fw/cli protocol.
Generally, the idea is to be verbose, explicit and reuse conventions, in order to enhance code maintainability and understandability for the other contributors.
docs/protocol.md got heavily updated
Many commands have been renamed for consistency. you are invited to adapt your client for easier maintenance
Guidelines, also written in docs/protocol.md "New data payloads: guidelines for developers":
- Now protocol data exchanged over USB or BLE are defined in netdata.h as packed structs and values are stored in Network byte order (=Big Endian)
- Command-specific payloads are defined in their respective cmd_processor handler in app_cmd.c and chameleon_cmd.py
- Define C `struct` for cmd/resp data greater than a single byte, use and abuse of `struct.pack`/`struct.unpack` in Python. So one can understand the payload format at a simple glimpse.
- If single byte of data to return, still use a 1-byte `data`, not `status`.
- Use unambiguous types such as `uint16_t`, not `int` or `enum`. Cast explicitly `int` and `enum` to `uint_t` of proper size
- Use Network byte order for 16b and 32b integers
- Macros `U16NTOHS`, `U32NTOHL` must be used on reception of a command payload.
- Macros `U16HTONS`, `U32HTONL` must be used on creation of a response payload.
- In Python, use the modifier `!` with all `struct.pack`/`struct.unpack`
- Concentrate payload parsing in the handlers, avoid further parsing in their callers. This is true for the firmware and the client.
- In cmd_processor handlers: don't reuse input `length`/`data` parameters for creating the response content
- Avoid hardcoding offsets, use `sizeof()`, `offsetof(struct, field)` in C and `struct.calcsize()` in Python
- Use the exact same command and fields names in firmware and in client, use function names matching the command names for their handlers unless there is a very good reason not to do so. This helps grepping around. Names must start with a letter, not a number, because some languages require it (e.g. `14a_scan` not possible in Python)
- Respect commands order in `m_data_cmd_map`, `data_cmd.h` and `chameleon_cmd.py` definitions
- Even if a command is not yet implemented in firmware or in client but a command number is allocated, add it to `data_cmd.h` and `chameleon_cmd.py` with some `FIXME: to be implemented` comment
- Validate data before using it, both when receiving command data in the firmware and when receiving response data in the client.
- Validate response status in client.
Disruptive changes:
- GET_DEVICE_CAPABILITIES: list of cmds in data are now really Big Endian
Note: the initial attempt to use macros PP_HTONS were actually considering wrongly that the platform was Big Endian (BYTE_ORDER was actually undefined) while it is actually Little Endian.
- GET_APP_VERSION: response is now a tuple of bytes: major|minor (previously it was in reversed order as a single uint16_t in Little Endian)
- SET_SLOT_TAG_TYPE: tag_type now on 2 bytes, to prepare remapping of its enum
- SET_SLOT_DATA_DEFAULT: tag_type now on 2 bytes, to prepare remapping of its enum
- GET_SLOT_INFO: tag_type now on 2 bytes, to prepare remapping of its enum
- GET_DEVICE_CHIP_ID: now returns its 64b ID following Network byte order (previously, bytes were in the reverse order)
- GET_DEVICE_ADDRESS: now returns its 56b address following Network byte order (previously, bytes were in the reverse order). CLI does not reverse the response anymore so it displays the same value as before.
- MF1_GET_DETECTION_COUNT: now returns its 32b value following Network byte order (previously Little Endian)
- GET_GIT_VERSION response status is now STATUS_DEVICE_SUCCESS
- GET_DEVICE_MODEL response status is now STATUS_DEVICE_SUCCESS
- MF1_READ_EMU_BLOCK_DATA response status is now STATUS_DEVICE_SUCCESS
- GET_DEVICE_CAPABILITIES response status is now STATUS_DEVICE_SUCCESS
- HF14A_SCAN: entirely new response format, room for ATS and multiple tags
- MF1_DETECT_SUPPORT response status is now HF_TAG_OK and support is indicated as bool in 1 byte of data
- MF1_DETECT_PRNG response status is now HF_TAG_OK and prng_type is returned in 1 byte of data with a new enum mf1_prng_type_t == MifareClassicPrngType
- MF1_DETECT_DARKSIDE response status is now HF_TAG_OK and darkside_status is returned in 1 byte of data with a new enum mf1_darkside_status_t == MifareClassicDarksideStatus
- MF1_DARKSIDE_ACQUIRE response status is now HF_TAG_OK and darkside_status is returned in 1 byte of data. If OK, followed by 24 bytes as previously
- MF1_GET_ANTI_COLL_DATA: in case slot does not contain anticoll data, instead of STATUS_PAR_ERR, now it returns STATUS_DEVICE_SUCCESS with empty data
- MF1_SET_ANTI_COLL_DATA and MF1_GET_ANTI_COLL_DATA now use the same data format as HF14A_SCAN
For clients to detect Ultra/Lite with older firmwares, one can issue the GET_APP_VERSION and urge the user to flash his device if needed.
On older firmwares, it will return a status=b'\x00' and data=b'\x00\x01' while up-to-date firmwares will return status=STATUS_DEVICE_SUCCESS and data greater or equal to b'\x01\x00' (v1.0).
Other changes: cf CHANGELOG, and probably a few small changes I forgot about..
TODO:
- remap `tag_specific_type_t` enum to allow future tags (e.g. LF tags) without reshuffling enum and affecting users stored cards
- TEST!
Bug when NRF_LOG_DEFERRED=0
due to a userland NRF_LOG_INFO after FDS record update was initiated, interrupted by FDS record IRQ handler and its own NRF_LOG_INFO
resulting in
<error> app: Fatal error
<warning> app: System reset
Added a few more NRF_LOG in FDS module as well.
Added NRF_LOG_FLUSH in system_off_enter to not miss last messages.
Philippe Teuwen
Thomas BurnhamandPhilippe Teuwen
dxl
Augusto Zanellato
Dominik Szymański