When reading the jedec device id the code only transfered one byte via spi leaving
the expected input buffer uninitialized. This may lead to the problem that flash
initialization fails because the expected input may be whatever the stack was set
when entering the function. The impact of the bug is somewhat limited tough as the
initialization usually takes place before starting up the rtos and thus is pretty
deterministic. So if the code passed init while testing it should pass init in
production as well.
When reading the jedec device id the code only transfered one byte via spi leaving
the expected input buffer uninitialized. This may lead to the problem that flash
initialization fails because the expected input may be whatever the stack was set
when entering the function. The impact of the bug is somewhat limited tough as the
initialization usually takes place before starting up the rtos and thus is pretty
deterministic. So if the code passed init while testing it should pass init in
production as well.
Previously, when unconnected, only the flighttelemetrystats
UAVO was Tx'd. All other UAVOs were inhibited. This led to
zero telemetry data when the connection to the GCS was gone.
This precluded getting useful telemetry from a receive-only
station.
This commit changes two main areas.
First, UAVO updates are now allowed regardless of the "connected"
state between the GCS/FC.
Second, it makes both the flighttelemetrystats and gcstelemetrystats
UAVOs un-acked. This prevents these objects from blocking all
other UAVOs while they wait for their ack. This is OK since the
real "connection" negotiation happens via the states exchanged in
the Status field of these UAVOs.
The USB VCP Port has a new DebugConsole setting that
routes all output destined for PIOS_COM_DEBUG to the
emulated serial port.
To enable this in your build, you'll have to build like:
- make fw_coptercontrol_clean
- make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES
You can then output formatted text to the console
like this:
#if defined(PIOS_INCLUDE_DEBUG_CONSOLE)
PIOS_COM_SendFormattedString(PIOS_COM_DEBUG,
"foo is %u\r\n",
foo);
#endif /* PIOS_INCLUDE_DEBUG_CONSOLE */
Please ensure that all of your debug output is
wrapped with these macros so that your debug
code doesn't bloat the firmware image.
Serial ports now have a new HW setting called DebugConsole
which can be used to dump internal state to a serial port
for debug.
To enable this feature, you need to:
- make fw_coptercontrol_clean
- make fw_coptercontrol ENABLE_DEBUG_CONSOLE=YES
- configure one of the serial ports as DebugConsole in the GCS
- save settings
- power-cycle your board
Things to note:
- The console is at 57600,8N1.
- This is not currently configurable via the GCS.
- You can only have a single console enabled at a time.
The SET_LINE_CODING request contains data and must be
handled as such.
Previously, the only requests that had data were IN
requests. SET_LINE_CODING is an OUT request so it
required additional changes to support a new type of
data request.
The CDC interface is always advertised in the FW USB
descriptors. It is NOT always enabled/initialized at
runtime. Specifically, it can be Disabled in HwSettings.
Previously, any CDC-related query that the host would send
resulted in an assert and a watchdog.
Now, a suitable return code indicating that the request is
unsupported is returned in this scenario.
