> On Sep 21, 2019, at 17:29 , dufa...@hda.com wrote: > > > >> On Sep 21, 2019, at 17:04 , Chris Johns <chr...@rtems.org> wrote: >> >> (…) >> The tester is designed to avoid cycling power. A clean working target should >> only need a single power on at the start and a single power off at the end. >> Repeated power cycling can stress power supplies and targets, some switch >> modes >> do not like it. Some targets have hardware reset issues and may need a power >> cycle and I have seen uboot get wedged. The power cycle logic is for those >> cases. I would not expect this being needed on each boot. Also it is a reset >> which can be a power cycle or a wired reset signal however some SOCs these >> days >> have separate power on reset (POR) logic and a reset signal logic. >> >> Chris > > You are bringing up most of my concerns in your response, I’ll go over your > response properly tomorrow AM when I’ll have free time. Thanks. >
I think if I change "rtems_test_assert()" to invoke "exit(RTEMS_FATAL_SOURCE_ASSERT)" instead of "exit(0)" and then use the following for the reset expression it will do what I would like. I'm sure there is a better way to do that regular expression but I'll use this for a test. target_reset_regex = .* RTEMS_FATAL_SOURCE_BDBUF, .*|.* RTEMS_FATAL_SOURCE_APPLICATION, .*|.* RTEMS_FATAL_SOURCE_BSP, .*|.* RTEMS_FATAL_SOURCE_ASSERT, .*|.* RTEMS_FATAL_SOURCE_STACK_CHECKER, .*|.* RTEMS_FATAL_SOURCE_EXCEPTION, .*|.* RTEMS_FATAL_SOURCE_SMP, .*|.* RTEMS_FATAL_SOURCE_PANIC, .*|.* RTEMS_FATAL_SOURCE_INVALID_HEAP_FREE, .* Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
