HCI Uart as a peripheral UART (BCM20737)

[Anonymous]

Hi,

I know that there is a few thread about the HCI UART but none explain why it is not possible to use the HCI UART as a peripheral UART.

As I understand it, the mode in which the UART will operate is based in the value of uart_rx during the reset.

HCI UART Rx = High (Programming mode)

HCI UART Rx = Low (Application mode)

And once in programming application, we can use it to output traces. If it can be used to output traces in application mode,

why can we not used it to transmit or receive anything ?

Is it really a limitation of the HW or just a lack of support for it the the Broadcom FW ?

Also, on the Anaren board, they short the SDA line to VCC to prevent the module from booting from the EEPROM to perform recovery.

According to them, that is how Broadcom does it also. Forcing a I2C line to VCC is not really I2C friendly. Is the idea only to prevent the reading from the EEPROM ? In that case, it seems that forcing the SDA to GND would be the way to do it.

Thanks,

Yves

[MichaelF_56 · Accepted solution]

Unfortunately, the HCI UART is not available for application use.

Essentially, with regards to I2C on boot, if VDDIO is present on SDA during boot up, then the firmware bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode (Re: How can BCM20732S boot from ROM?)

However, the previous entries in this post seem to imply that you can also GND the SDA pin and see the same behavior: Re: Re: How can BCM20732S boot from ROM?

Connecting SDA to Vdd/Vio to recover is probably not optimal for the following reason provided to me by one of the senior firmware engineers.

SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.

If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.

Shorting to GND on the other hand, is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line.

[Anonymous]

What is the purpose of forcing a ROM boot by preventing the module from reading the EEPROM ?

It seems to do exactly the same thing than forcing programming mode by forcing the HCI UART RX pin high during the reset.

Is the module "more" in recovery mode if both methods are applied at the same time ?

[asridharan]

When you force a ROM boot, patches and app are not loaded and initialized. But when you put the device in download mode by driving HCI RXd high, it ill still load and initialize all patches, and invoke the APPLICATION_INIT() function (but will not init the stack or the app by calling appliction_create). So there is a difference in the boot sequence.

[Anonymous]

Thanks,

That is a very clear answer.