Pavel Pisa commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5537#note_147874 Some more testing. I have analyzed how, why interrupts processing works when I run code from internal SRAM and do not have proper RTEMS image and its start vector table stored at the start of Flash (from address 0x00000000). And the `ticker.exe` works thanks to some unrelated application Flashed into memory. The original application starts by ``` 0x0: b 0x7680 0x4: b 0x4 0x8: b 0x8 0xc: b 0xc 0x10: b 0x10 0x14: b 0x78b0 0x18: ldr pc, [pc, #-432] @ 0xfffffe70 0x1c: ldr pc, [pc, #-432] @ 0xfffffe74 ``` The last two instructions ensure that interrupt and FIQ service routine address is taken from VIM which is reset to `_ARMV4_Exception_interrupt` for all IRQ vectors. This setup is not optimal for case that there is some random code reminder in the Flash. The TMS570LC4357 BSP keep our logic from TMS570LS3137 BSP for internal SRAM and SDRAM builds which replaces vector table targets in Flash by start of the internal SRAM whith the help of POM module (see `tms570_pom_remap`). But there has been problem that only data has been fetched reliably from POM overlay on TMS570LS3137, so the design expect that Flash starts with eight `ldr pc, [pc,#0x38]` instructions and then only data part (jump target addresses) of the vector table from `0x00000040` to `0x00000040` is replace by POM. But because do not have proper startup code Flashed in the chip, I have tried to return to replacement of the whole block instructions and data in the whole `0x00000000` to `0x00000040`. This seems to work so it is possible that the issues with instruction fetching from POM overlay is not present on TMS570LC4357. This would be great because code with next changes should allow to test it from internal SRAM even if the chip Flash is fully erased or filled by some unrelated/incompatible content. The modification for full vector table replacement by POM is there ``` diff --git a/bsps/arm/tms570/start/tms570-pom.c b/bsps/arm/tms570/start/tms570-pom.c index 82e9389785..d465f05cd6 100644 --- a/bsps/arm/tms570/start/tms570-pom.c +++ b/bsps/arm/tms570/start/tms570-pom.c @@ -108,7 +108,7 @@ void tms570_pom_initialize_and_clear(void) void tms570_pom_remap(void) { void *vec_overlay_start = (void *) pom_global_overlay_target_address_start; - void *addr_tab = (char *) bsp_start_vector_table_begin + 64; + void *addr_tab = (char *) bsp_start_vector_table_begin + 0; if (vec_overlay_start == addr_tab) { return; @@ -124,10 +124,10 @@ void tms570_pom_remap(void) * table found in * bsps/arm/shared/start/start.S */ - rtems_cache_invalidate_multiple_data_lines(addr_tab, 64); - memcpy(vec_overlay_start, addr_tab, 64); - rtems_cache_flush_multiple_data_lines(vec_overlay_start, 64); - rtems_cache_invalidate_multiple_instruction_lines(vec_overlay_start, 64); + rtems_cache_invalidate_multiple_data_lines(addr_tab, 128); + memcpy(vec_overlay_start, addr_tab, 128); + rtems_cache_flush_multiple_data_lines(vec_overlay_start, 128); + rtems_cache_invalidate_multiple_instruction_lines(vec_overlay_start, 128); #if 0 { @@ -154,9 +154,9 @@ void tms570_pom_remap(void) * (opcode 0xe59ff058) then the jump target addresses are replaced * by pointers to actual RTEMS exceptions service functions. */ - TMS570_POM.REG[0].PROGSTART = TMS570_POM_PROGSTART_STARTADDRESS(64); + TMS570_POM.REG[0].PROGSTART = TMS570_POM_PROGSTART_STARTADDRESS(0); TMS570_POM.REG[0].OVLSTART = TMS570_POM_OVLSTART_STARTADDRESS(vec_overlay_start); - TMS570_POM.REG[0].REGSIZE = TMS570_POM_REGSIZE_SIZE(TMS570_POM_REGSIZE_64B); + TMS570_POM.REG[0].REGSIZE = TMS570_POM_REGSIZE_SIZE(TMS570_POM_REGSIZE_128B); TMS570_POM.GLBCTRL = TMS570_POM_GLBCTRL_ON_OFF(0xa) | TMS570_POM_GLBCTRL_ETO(0xa) | (TMS570_POM_GLBCTRL_OTADDR(~0) & ``` I have checked that the interrupt service routine is reached by POM path and not through VIM workaround. It seems to be working well on TMS570LC4357 but do not rely on it in the production environment. Only safe way for available RTEMS options is to run code from Flash. But if it is found that POM way is reliable on TMS570LC4357, then it simplifies development a lot. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5537#note_147874 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
