Hello, I have a question about clock settings for CW308T-AURIX.
The Hardware Product Documentation for the CW308T-AURIX states
The TC233LP currently requires a 7.37MHz clock from the ChipWhisperer. The PLL is setup to run at x1 speed (so still 7.37MHz).
However, looking at g_PllInitValue_20_10 specified as DEFAULT_PLL_VALUE in aurix_hal_sys.c, it appears that it is using a 20MHz clock as the source instead of 7.37MHz.
Also, if we examine PLLCON0 and PLLCON1, it appears that Fcpu is also set to 20[MHz] at this time. This is equivalent to the “x1 speed” in the documentation.
Since the firmware only works when I actually output a 7.38MHz clock to HS2 on the Chipwhisperer, it certainly seems to be using a 7.38MHz clock, but I can’t see where I am making a mistake in my calculations. Could you please point out the error?
My goal is to change the target clock to any value I want and proceed with the course.
Hi,
I haven’t looked at the AURIX, so I don’t remember exactly how everything is setup, but I’m guessing that OSCVAL doesn’t really matter here (maybe because we’re using an external clock instead of an oscillator?). The 7.37MHz clock is necessary for the UART to be at the correct baud rate. You should be able to input a 20MHz clock and scale the baud rate accordingly.
Alex
Hi Alex,
As you told me, I understood that the reason for the 7.37 MHz clock required is to set the UART baud rate to 38.4 kbps, which is the Simpleserial V1.1 standard. I think the reason why the OSCVAL value did not matter in this case is because OSC_WDT was disabled in the SMU_AG3CFx register.
The baud rate scaling confused me a bit: aurix_hal.c has the baud rate formula as a comment, but since CCUCON0.SPBDIV is set to 2, fa = fclc = fspb = fpll0 (=fosc) / 2, so the formula fosc is actually should be fosc / 2.
After adjusting BAUD_NUM using the above calculation, I can communicate correctly with the target at 20MHz. Thanks for your help.
By the way, increasing the clock to 20MHz made the voltage glitch less successful. Also, the glitch width(%) needed to be wider. I assume this is because a too short glitch would not reduce the core voltage sufficiently.
In general, glitching is easier if the target clock is slower? Also, what is the upper limit of clocks at which effective voltage glitching can be done with Chipwhisperer? At least, I feel that the switching speed of the MOSFETs would be an obstacle for targets running at clocks above 100MHz.
Good to hear that worked for you.
Needing a wider glitch when you increase the clock rate makes sense because the width/offset of the glitch are based on the CW’s clock. If you increase the clock frequency, a 20% width will be shorter in time. Eventually, you’ll need to switch over to enable_only glitching, which keeps the glitch on for a full clock cycle.
Alex
1 Like