ouch. I think SCB_SHPR(shpr_id) should be kept as is, but the comments are not helpful, and yes, the current definitions of SCB_SHPR1..3 are really the same as SCB_SHPR(1) and SCB_SHPR(3) which is not really what you'd expect.
Further, I don't think the definitions of SCB_SHPR1_PRI_XXXX are helpful either. They look somewhat designed to be used with the whole 32 bit register names, rather than the nice byte sized chunks setup with the SCB_SHPR() macro. I've pushed one way of tidying this up to: https://github.com/karlp/libopencm3/commit/92bdde582b2e6dcc51d224add029ea43c7e110da which is one way of doing this, but I'd like some other opinions on this first. Anyone? The way you'd use it then would be... SCB_SHPR(SCB_SHPR_PRI_15_SYSTICK) = SYSTICK_PRIORITY_SE; No shifting, and no need to care about which damn register it's in. Speaking of shifting, I'm a little surprised that gcc wasn't warning you about shifting left 24 and then storing it in an MMIO8? On 07/17/2013 05:28 PM, Donald E Haselwood wrote: > I think there is a mistake in scb.h-- > > /* SHP: System Handler Priority Registers */ > /* Note: 12 8bit registers */ > #define SCB_SHPR(shpr_id) MMIO8(SCB_BASE + 0x18 + > shpr_id) > #define SCB_SHPR1 MMIO8(SCB_BASE + 0x18 + > 1) > #define SCB_SHPR2 MMIO8(SCB_BASE + 0x18 + > 2) > #define SCB_SHPR3 MMIO8(SCB_BASE + 0x18 + > 3) > > I think these should be defined as-- > MMIO32(SCB_BASE + 0x18) > MMIO32(SCB_BASE + 0x1C) > etc, > > I ran across the problem with setting the priority of the SYSTICK > interrupt priority. The first of the following instructions works > correctly, the second does not. > > *(u32*)0xE000ED20 |= (SYSTICK_PRIORITY_SE << 24); > > SCB_SHPR3 |= (SYSTICK_PRIORITY_SE << 24); > > Both load the correct address into the R3, then load R2 with the > register. However, the first of the above "or's" in the priority > correctly, the second simply stores without or'ing in the shifted > priority. No gcc warnings either. > > I'm using the earlier svn based libopenstm32, but I downloaded the > latest 'cm3 and I find it is still the same. > > Maybe someone could fix this. I'm not sure how to go about do it. > > Don > > PS: This resulted in an extremely vexing bug where the situation > required the systick interrupt to be at a lower priority than an adc > register watchdog interrupt. The result was an infrequent glitch that > only occurred under certain circumstances. The systick priority, of > course, was defaulting to level 0. > > > > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > libopencm3-devel mailing list > libopencm3-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libopencm3-devel > ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ libopencm3-devel mailing list libopencm3-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
