rebased

needs rebase

rebased.

not good. Will check.

I have a different behavior here: tests/periph_gpio and tests/i2c work as expected, but default goes into hard-fault once I input something to the shell...

mhm, I just made one pass, so I was lucky on some - but in general its not deterministic?

@haukepetersen: yep now example/defaults failed for me, too 😢

To simplify things, I am looking into tests/shell right now. As the shell works with the tests/periph_gpio test, I con't expect this too be a problem with the uart driver, but rather something more system related.

What I can tell so far: tests/shell fails with this PR (hard fault on rx), but if I comment out the DISABLE_MODULE += auto_init in the Makefile, then it works... But no idea what this means so far.

seems like we broke the board/cpu a while back. git bisect lead me to believe that dd49f22 broke the board, though I can't really tell why this is.

but that commit would break then all cortex-m based CPUs which it certainly doesn't because others still work.

Just tried it: manuall reverting the changes from dd49f22 on the current master makes the nucleo-l152 behave as expected again. So something is with this change that the l1 doesn't like.

@haukepetersen the difference is that irq_restore is mapped to irq_arch_restore which is

/**
 * @brief Restore the state of the IRQ flags
 */
void irq_arch_restore(unsigned int state)
{
    __set_PRIMASK(state);
}

problem: it doesn't call __enable_irq() while irq_disable() is mapped to irq_arch_disable which is:

/**
 * @brief Disable all maskable interrupts
 */
unsigned int irq_arch_disable(void)
{
    uint32_t mask = __get_PRIMASK();
    __disable_irq();
    return mask;
}

and does __disable_irq()

so __enable_irq() -> __ASM volatile ("cpsie i" : : : "memory");
and restore: -> __set_PRIMASK(state);

we can say for sure, that replacing these to lines does not result in the same functions called, at least the now used restore does something different and does not call __enable_irq(), I wonder why other platforms are not showing this behaviour. I mean I mostly tests with remote-revb and PhyNode (pba-d-01-kwx2) which are both cortex-m as well, but so far no problem with them.

we can say for sure, that replacing these to lines

as in the commit by @vincent-d you found

ah forget about the remotes, they do not use cortexm_sleep so they shouldn't be affected, but maybe its a similar problem why I had to exclude them.

Just put the question into #7385. Either there is a quick fix, or this will be one of those hard to fix issues...

Anyway, I am pretty sure the issue at hand is unrelated to the changes in this PR. Would you be ok with merging this PR and keeping track of the broken stm32l1 in a different place?

This needs rebase @haukepetersen.

Maybe @kYc0o you can give this one a try (since you seem to also have the hardware) ?

needs rebase

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

as such changes are done for other MCU already, this should be moved forward (again). Hence, don't close.