We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Could you help me to solve the problem.Do you have the code to verify the thumb instruction ? If have,the code can check any corner the functions of thumb instructions
Hi there,
Haiyan already gave you good information about possible cause for the HardFault.
To debug the issue, you should:
- generate disassembly code of the program image to see what instruction is being execute at the point of failure
- see the state of registers to see exactly which address you are accessing, and if there is any address alignment issue
- understand the memory map of the device to see if the error is caused by an access to illegal address.
From there you should be able to pin point the cause of the HardFault - typically software bugs like attend to generate unaligned access or invalid pointer location (end up with bus error).
We use many verification methodologies for processor verification. Unfortunately many of our verification technologies requires specialize verification environments (e.g. simulations, formal verification) and these cannot be use in physical chip devices (especially the memory size and system characteristics is limited in these devices). If you want to learn more about CPU verification, you are welcome to join Arm
https://www.arm.com/company/careers
regards,
Joseph
#pragma location = 0x0001bf0
__root const int16_t TAB_SoftVer[21] ={0,-1,-2,3,4,5,6,7,8,9,10,1,2,3,4,5,6};
//const INT16U TAB_SoftVer[14] @"romdata" ={0x0000,0x1111,0x22222,0x3333,0x4444,0x5555,0x6666,0x77777,0x8888,0x9999,0xaaaa,0xbbbb,0xcccc}; //软件版本（内部用）
__no_init INT8S Ram_Dat[5]@ 0x20000100;
Ram_Dat[0]=-2;
Ram_Dat[1]=-1;
Ram_Dat[2]=0X69;
Ram_Dat[3]=-5;
Ram_Dat[4]=0X66;
__asm(
"NOP\n"
// "NOP\n"
"LDR R4,RAMDAT_ADDR\n"
"LDR R0,ROMDAT_ADDR\n"
"LDRSB R2 ,[R4,R2]\n"
"MOVS R3 ,#3\n"
"LDRSB R4 ,[R4,R3]\n"
"SUBS R2,R2,R4\n"
"LSLS R2,#24\n"
"ASRS R2,#23\n"
"LDRH R2,[R0,R2]\n"
"RAMDAT_ADDR: DC32 0x20000100\n"
"ROMDAT_ADDR: DC32 0x0001bf0\n"
);
the RAMDAT_ADDR is the address of Ram_Dat[5]，the ROMDAT_ADDR is the address of TAB_SoftVer.
when it run at "SUBS R2,R2,R4\n" , R2 is wrong , when R2 is 0xFFFFFFF8,R4 is 0xFFFFFFF0, the result of R2 is 0x40800008.
The frequency of core is 11Mhz.
.
Joseph Yiu said:understand the memory map of the device to see if the error is caused by an access to illegal address
hyue: in addition, note that (some?) chips will give a hardfault if you try to access a peripheral which has not been enabled.
So, as well as ensuring that an address is legal, you also have to ensure that it is in a valid state.
Some chips allow you to turn off parts of the memory to save power - I guess that could also be a source of a hardfault if you try to access disabled memory ... ?
Hi Andy,
That's true. But as the question is about memory testing, I would expect the program would have enabled the memories before starting the test ;-)
(Note: for memories it is less common for it to be disabled at start. e.g. imagine you want to place the stack at the top of the RAM and by default that memory range is disabled, your SystemInit and C startup code won't be able to run).
What is the initial state for R2 when you run the test? ( D2 ? ;-) )
Is it an FPGA prototype?
We have run the code on an FPGA，the result of R2 is 0x08. But only the one chip is bad, others run the same code is OK。We try to pick pu bad chips which have the same problems, when test chip in FT. But we don't know how to check the functions of CM0,Can you give me some methods?
For chip production tests, usually for logic (i.e. the processor and the processor system logic excluding RAM) should be tested using scan tests. Before tape out, you should also run LEC (Logic Equivalent Checking) to ensure that that netlist matching the RTL.
For memory macros, you can add memory BIST (this is done outside of processors). You need to check the EDA tool manuals on how to do that. You could run software based memory tests, but there is an issue - if the chip is bad, how can you be sure the software to test memory is running correctly?
If you google for "memory testing algorithms" you should find plenty of resources.
the memory and flash of bad chip is good , We have tested them. We have tested CM0 logic by DFT, but is ok. Only the instructions (SUBS R2,R2,R4 ) is wrong, no matter the SUBS in SRAM or FLash
Is this a timing path issue? Does it fail when running at lower frequency?
In general we expected DFT to pick up this kind of issues. There are some limitations with DFT, for example, timing violations might not be picked up by DFT because scan clock usually run slower, and defects could be hidden as clock signal's characteristic could be very different in scan mode. But test coverage of software tests are usually much lower than DFT. In general, DFT is the recommended test method.
This is a timing issue, when it runs at lower frequency,the result of SUBS R2,R2,R4 is correct.So we want to pick up those bad chips by running code. But how to pick up?
Can you do at-speed test with scan chains?
Never do this before，How to do at-speed test with scan chins？
It is similar to normal DFT scan test, but the capture cycle (gap between last shift to capture clock edge) is using normal clock speed.
https://www.eetimes.com/document.asp?doc_id=1217753
Thank you very much!