Fixes HWCDC::end()

[SuGlider]

Description of Change

If we call serial.end() followed by serial.begin using JTAG/CDC interface, it will never initialize the semaphore tx_lock and it will reset the board when data is written.
There is a missing tx_lock = NULL; in the HWCDC::end() function.

Tests scenarios

Tested with C3 and S3.

Related links

Fixes #8224

[mrengineer7777]

LGTM

[TD-er]

Yep, very complex fix :)
LGTM.

I will also have a quick look at the other static values to see if we might have missed others too.

[TD-er]

While we're at it, maybe also initialize the rx_data_buf to 0?

static uint8_t rx_data_buf[64]{};

I did a quick search for other calls of vSemaphoreDelete and there are more places where the pointer isn't set to NULL afterwards. This isn't an issue In destructors where the pointer used is a member.
But in esp32-hal-tinyusb.c it is a good candidate for future bugs when that function is later extended. (now it is a local variable inside that function and the function is left after this delete call)

[SuGlider]

While we're at it, maybe also initialize the rx_data_buf to 0?

Ok, done.

I did a quick search for other calls of vSemaphoreDelete and there are more places where the pointer isn't set to NULL afterwards. This isn't an issue In destructors where the pointer used is a member. But in esp32-hal-tinyusb.c it is a good candidate for future bugs when that function is later extended. (now it is a local variable inside that function and the function is left after this delete call)

esp32-hal-tinyusb.c uses the semaphore internally only.
It will never be extended because it is just used to check the installation of the JTAG driver.

I found vSemaphoreDelete with "no NULL" in HardwareSerial::~HardwareSerial() and TwoWire::~TwoWire(), but those are the destructors and all object memory will be gone anyway. The construtor will set it to NULL.

All other places are fine.