We produced several working devices with W7500P controlled by superior MCU. The MCU is able to switch W7500P to BOOT mode a upload firmware into it.
Now, we experinece problems with newly made devices. Sometimes, we can upload firmware into W7500P but our application doesn´t run properly - then we can observe on PA_02 (CLKOUT) wrong internal RC oscillator frequency 11.3 MHz or similar. Somtimes, we aren’t able to program W7500P firmware in BOOT mode at all - we can’t receive ‘U’ character as response during Baud rate detection inside W7500P boot program.
Power supply 3.3V is smooth.
Any ideas where can be the problem, what can we do?
RC oscillator is not calibrated?
What is the meaning of responses from W7500P to test character ‘U’ during Baud rate detection in boot mode, can we calculate frequency inaccuracy from it?
Thanks in advance for any help.
It’s a very unusual situation.
In boot mode, the clock frequency is 8 MHz.
Does all of your W7500P show symptoms like this? Or is it just one?
I think your W7500P is shocked. So it doesn’t working normally.
Is there a cause of shock in your environment?
Thank you for reply Scott.
Shocks caused by us are very unlikely, we manufacture electronics many years without any issues of that kind.
We manufactured 6 devices with W7500P in last few days, most of the W7500P chips behaved as described earlier. We tried to replace the W7500P on 2 boards, it helped in one case.
Still can’t figure out where is the problem.
I have faced with the same ISP programming issue on few W7500P microcontrollers!
In most cases ISP programming is completed successfuly. But i found few W7500P chips with the same bug. When i send “U” (0x55) command few times to start the programming process the W7500P returns errorneous bytes. I have no idea what they can mean:
received 0x5B 0x7F -1
received 0x66 0x7D -1
received 0x13 0x7C -1
received 0x7C -1
received 0x60 0x7E -1
received 0x7E -1
received 0x7C -1
received 0x60 -1
received 0x40 -1
I know that successful negotiations must be like that:
received 0x19 0x7F -1
received 0x66 0x7A -1
received 0x55 0x31 0x2E 0x32 -1
The last answer means the version of the bootloader U1.2
Please, i need technical support!
How can we fix errorneous negotiations?
Yes, in your case it could have been the same problem as ours, wrong RC oscillator frequency.
As i found out, W7500P in boot mode is able to accept communication at speeds 460800, 230400, 115200, 57600 Bd in the first four negotiation steps (I have tried and don´t suggest programming firmware at the speed 460k8). After entering boot mode, W7500P awaits ‘U’ character at a speed 460k8. Then, when it receives some other character, it will be able to accept ‘U’ at a half speed in the next step. The first character sent back by W7500P is the first character received, sent at W7500P’s listening speed.
You could try to change the communication speed on PC to 163000 Bd or some other and check if it will allow you to program the chip. But even if yes, it’s not a solution of the problem with the chip.
Thank you for reply!
I’ve tried to change baud rate but it didn’t help!
At 57600 baud rate chip returns only first valid symbol 0x55 but do not returns other valid symbols (0x31 0x2E 0x32 0x0D).
As the result no further communication is possible.
I have found that the internal RC oscillators have frequencies 10,55MHz 11,13MHz and 11,2MHz on those defected chips!
Now I’m sure the problem is the same as described by cauves. It is very disappointing that the amount of defected chips is so great in party! The 3 of 13 are defected. The only consolation is that these chips can be programmed through the SWD interface.