• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 114 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Prefetch abort after modifying pbistIsTestCompleted

f zl
Prodigy 20 points
Part Number: TMS570LS1227
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

The sys_selftest.c generated by HalCoGen contains this function:

Fullscreen
1
2
3
4
boolean pbistIsTestCompleted(void)
{
return ((systemREG1->MSTCGSTAT & 0x1U) != 0U);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


It violates MISRA-C 2004 12.2 "Volatile variable in complex expression", so I replace it by this equivalent function

Fullscreen
1
2
3
4
5
boolean pbistIsTestCompleted(void)
{
uint32 stat = systemREG1->MSTCGSTAT;
return ((stat & 0x1U) != 0U);
}
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

After this modification, the system goes into prefetch abort exception. nError pin seems to go wild that a relay controlled by that pin switches back and forth.

The registers are CP15.IFSR=0x0d, CP15.IFAR=0xc3c3c3c2 (an invalid address), CP15.AIFSR=0x0.

If I undo this modification, the prefetch abort disappears. If I add it back, the prefetch happens again. If I run the code in debugger step by step, the prefetch disappears.

I think it isn't my code that causes this problem because it goes to prefetch exception before running main(), and the code runs before main() is generated by HalCoGen, except pbistIsTestCompleted.

Although the C code seems equivalent, the assembly is quite different. But I can't see why it has anything to do with prefetch abort. Compiler flags are -mv7R4 --code_state=32 --float_support=VFPv3D16 --include_path="C:/ti/ccs1260/ccs/tools/compiler/ti-cgt-arm_20.2.7.LTS/include" --include_path="C:/ti/Hercules/F021 Flash API/02.01.01/include" -g --symdebug:dwarf_version=3 --c99 --diag_warning=225 --diag_wrap=off --display_error_number --gen_func_subsections=on --gen_data_subsections=on --enum_type=packed --abi=eabi.

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
boolean pbistIsTestCompleted(void)
{
return ((systemREG1->MSTCGSTAT & 0x1U) != 0U);
}
pbistIsTestCompleted():
000176cc: E3E0C097 mvn r12, #0x97
000176d0: E59C1000 ldr r1, [r12]
000176d4: E3A00000 mov r0, #0
000176d8: E3110001 tst r1, #1
000176dc: E3A0C000 mov r12, #0
000176e0: 0A000000 beq $C$L11
000176e4: E3A0C001 mov r12, #1
$C$L11:
000176e8: E35C0000 cmp r12, #0
000176ec: 0A000000 beq $C$L12
000176f0: E3A00001 mov r0, #1
315 }
$C$L12:
000176f4: E12FFF1E bx lr
boolean pbistIsTestCompleted(void)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Why does this happen? How can I locate the problem? Thanks very much!

  • +1
    TI__Guru 63045 points

    Hi,

    You are totally correct, i could see the same behavior at my end.

    So, i modified the variable declaration as below:

    This solved the issue, i mean maybe creating a variable in RAM memory creating the issue. That is the reason i choose to allocate register for variable and it solved the issue at my end.

    Please test with this and also do the MISRA validation and let me know the result.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 20 points

    Adding register keyword in the declaration solves the problem. It doesn't violate MISRA rules that my static analysis tool checks. Thanks for the solution!