RTEMS | TMS570 BSP has long term broken initial SRAM tests which has been unmasked by my previous fix (#5547)

[Pavel Pisa (@ppisa)]

Pavel Pisa created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5547



## Summary

My previous fix has exposed more breakage if internal SRAM self-tests is run when code starts from Flash or external memory. The previous negated option has disabled SRAM self-test in these cases and enabled it for code running from SRAM which lead to code self-clear.
    
But when code is running from Flash and full safety should be achieved then then SRAM test run through nested function
    
  /* ESRAM Single Port PBIST */
  tms570_pbist_run_and_check( 0x08300020U,
           (uint32_t) PBIST_March13N_SP )
    
lead to situation when lr and r3 could not be restored in return from this function. Memory content has been overwritten by tests.

The problem has been introduced by commit

b995211907aee43d0b23c3764cd342aae2afd10f bsp/tms570: Add tms570_pbist_run_and_check()
    
Which is cross-referenced with issue #4982.

Problem is that it uses wrapper with calling even for SRAM test when stack is placed in SRAM.

## Steps to reproduce

When tms570ls3137_hdk or tms570ls4357_hdk variant is build and flashed then system ends with fatal error which keeps error pin set even over reset.

The proposed solution will follow. It return mostly to previous state based on our work.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5547
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260406/577c3c11/attachment.htm>