1) Is the customer trying to download his FW into the sFlash or RAM?
2) What SW tools is the customer using? Is it the chipload+CGS combination?
3) If there is no response to RESET, did the customer do a power reset and attempt a RESET again?
4) Did the customer mount the module onto a jig for this purpose?
> 3) If there is no response to RESET, did the customer do a power reset and attempt a RESET again?
If they try to power reset, they will get 2 result.
If OK, could you tell us the what is the reason?
As I said,
>BTW, this issue was happened in the customer MP line
>so we can not test such complex test ,
>such as "recovery mode" ,unfortunately.
they can not try to power reset for every module(Be failed).
It is not easy to ascertain the root cause, as it could be HW (due to the test jig or contact/pogo pins) or SW (download tools).
I assumed the customer filtered the "bad" modules, can these modules be re-programmed again later?
Can you respond to (1), (2) and (4) to help me understand your environment?
Sorry for some questions.
>1) Is the customer trying to download his FW into the sFlash or RAM?
Regarding the issue, what is the difference between writing FW into Flash or RAM?
>2) What SW tools is the customer using? Is it the chipload+CGS combination?
Sorry, what does CGS mean?
>4) Did the customer mount the module onto a jig for this purpose?
Can you explain the [this purpose] here, what is the purpose?
1) Typically the FW is written into the on-board sFlash for storage and the application can be recalled upon power cycle. On the other
hand, RAM download will lose whatever that is on the RAM upon power cycle. The reason I asked this is because the link you attached
in your first post in on RAM download. Can you clarify whether is it RAM or sFlash download?
2) "chipload" and "CGS" are two pieces of SW we used to download FW into the sFlash on the module. They are located in the SDK.
Otherwise, what SW tools did your customer use to download the FW?
3) The "purpose" here refers to the downloading process. Did your customer secure the module onto a mechanical test-jig to download the FW?
Thank you for your explanation.
We are waiting for customer response.
Please wait for a moment.
Customer is planning to write to sFlash.
In their view,
Currently they want to confirm that why is no Reset command response,
there is no relationship between RAM and sFlash.
Customer's procedure at production line:
1) Mount the BT-Module on their PCB.
2) Fix the PCB mounting the BT-Module on the test jig.
3) Connect PC and USB serial conversion cable to the check PIN (BT-Module terminal) of PCB,
(The initial state of BT-Module is not written. It remains as delivered BT-Module.)
4) Send HCI Command RESET_Command using PC application (TeraTerm macro).
Macro: "send $ 01 $ 03 $ 0 c $ 00"
5) When normal, the response of "04 0E 04 01 03 0C 00" is received,
but 2 out of 11 could not receive the above response.
Ok, forget about the RAM thing.
So you soldered the module onto a motherboard, connect a test PC to it via a USB-to-serial converter to
issue your HCI commands.
1) Can the customer insert a 1s delay after powering up the board before he issue his HCI_RESET command?
2) Can the "failed" boards be reprogrammed again offline?
Can you also ask the customer the provide a log for the download process? If they do not have this feature, please make a request to them.
Please provide me a "Pass" and "Fail" log.
Can you tell me why let customer inserts the 1 second Delay?
If OK, what is the problem?
I am not completely sure of what you mean.
Your opinion, insert 1 second delay, once again
1,confirm whether customer can get response.
2,Or, it is mandatory to program FW to the module,
and finally confirm whether the FW is completely written.
Which one is what you want?
A pause of 1s after turning on the power supply is to ensure that the chip is fully power up. There are occasions in the factory in which the HCI commands are downloaded immediately after turning on the power supply but the HCI port has not been detected. Or the usb-to-serial converter may need some time to detect the serial ports when you change out your PCBs. This is especially so on often-old PCs in the factories.
I cannot pin-point the cause to be honest. I am just sharing some good practice here.
1) Power up board
2) Wait for 1s
3) Issue HCI command (Reset)
Can the "failed" boards be reprogrammed again offline?
Please include a case number (no links).