Closed jadonk closed 2 years ago
Hello Jason, according to the master and slave devices has different to silkscreen, we recommend using the master device silkscreens on the front of the BeagleConnect and the slave device silkscreens on the back. Do you think it is feasible?
No, it should be socket/master in both cases. The socket is female, the add-on board uses male.
Okay, got it
I don't believe the CC1352 has an easy way to detect the status of MB1_CTRL. It seems that this could cause some potential for device damage. We can do some monitoring of RX before we enable TX on the CC1352, but USB could be hot-plugged, resulting in the CC13520 TX being connected to MSP430 TX.
I'm unclear when this could be fixed in hardware--ie., can this be fixed before the larger production run. First-pass pilot run is already done.
We have tested it and there are no problem. We will continue the aging test this week and give you the results next Monday.
After the aging test, there is indeed a problem, is dealing with the problem.
We switched the Pin 13 and Pin 14 wires on the J4 holder to avoid this problem, as follows:
OK. We'll need to have some version indication so we can apply the software work-around.
I think we could change the hardware schematic version from C5 to C6 and send you the latest schematic, can we?
Schematic is good, but we need some software indication so that the old hardware can still work, I think.
According to the mikroBUS specification, the socket labels are based on the perspective of the MCU, meaning the RX pin on the socket in the following diagram should be connected to the RX pin on the MCU.
This is described in more detail in the section below showing how add-on boards should be labelled and connected in the opposite way.
This could be swapped in software, except the bootloader is configured in the alternate manner, as well as the connection to the MSP430.
Hey @vaishnav98, wouldn't you have seen this issue on the GPS/GNSS Click boards?
cc @ChrisGammell @statropy @Pillar1989 @FionaYu20180326