pabigot / bsp430 Goto Github PK

The exp430f5438 locks up periodically when running a console at 115200 and an undivided 4MHz SMCLK timer with overflow enabled. Need to isolate this and determine if it's a bug or mis-use of resources.

When a timer source is asynchronous to MCLK, the MSP430 does not guarantee that reading the counter produces valid results. A majority-vote solution is workable when the timer is slow relative to MCLK, but not when they are comparable speed. The problem can be avoided by loading the counter into a CCR register and using that value.

int iBSP430timerCCCount (tBSP430periphHandle handle);

Backport the basic functionality from test430

Is there a usb library support on the roadmap?

Contiki's LED API apparently finds this valuable.

When interrupts are disabled by a callback, the current code improperly sets IFG when it clears IE. It should leave IFG alone unless told by the callback that no character was output.

The interrupt declaration for port interrupts improperly includes TIMER before the instance vector.

Specifically _ni standard and how to preserve interrupts.

struct sBSP430timerAlarmData does not have a typedef equivalent, while other structs do. Review the usage and check that the coding standard describes the proper policy on creating these.

Add a utility module supporting an M25P serial flash. Provide standard names for common commands and status bits, and wrappers for basic operations. The interface should support both programmed I/O and DMA transfers.

This was one of the first features in BSP430, and the architecture does not match current needs. It should provide peripheral-specific functions to clear any clock and specific clocks, and to test for faults in any clock and specific clocks. These should be overridable when user needs differ.

There should be a generic interface supporting an instance-specific EUI48 or EUI64 for platforms. In many cases a default one can be derived from TLV information such as die position; in other cases the platform may be able to derive one from a peripheral like a DS18B20; or there may be one stored in information memory. Reference Linux policies for automatically creating MAC addresses when providing metadata (e.g. that the number was randomly assigned so conflicts could occur).

Something that prints a message, then locks up blinking the LEDs would do

The pending uptime-linked delay infrastructure in #27 expects GIE to be cleared on wakeup returns. The console interrupt handlers do not support clearing GIE on return which means that a delay might wake early and leave interrupts enabled if somebody hit a key on the console.

Whether GIE is cleared whenever the processor is active is an application policy decision that must be respected by the BSP430 infrastructure, probably in BSP430_HAL_ISR_CALLBACK_TAIL_NI.

The patch in SHA: bb9ffa5 introduced a macro that is only defined when SPI is enabled, but the SPI routines are compiled unconditionally.

EXP430G2 uses TA1 instead of TA0 for the uptime timer. The default resource management in bsp430/platforms/bsp430_config.h does not recognize that the correct resources were defined in the platform config file. Need a mechanism to convey that, or need to bypass the default on this platform.

The current solution requires that a clock and divisor be provided, which is inconvenient when the bus speed is important but clock speed might vary. Use a zero divisor as a cue to calculate the preferred clock and divisor from a configurable constant like BSP430_SERIAL_I2C_BUS_RATE_HZ.

BSP430_CORE_DELAY_CYCLES is fine for short delays; for values starting at about 1ms we really want to be able to enter LPM. Add infrastructure for this.

FLLPLUS has a facility to set XCAP configuration; other clocks need it too.

Several CLI functions use _ni-qualified console output routines, which can result in GIE being disabled as a side effect, which in turn can cause the application to hang, especially when CLI diagnostics fill a transmission buffer and the system has to block for it to flush.

Need to use the GPIO ports with their interrupt functions. Which module(or example) you would recommend me to look. Basically I am using the launchpad platform and would like to catch events on the GPIO ports. there is the periph.h and port.h files. But kinda confused which is the correct one to work with. Any suggestions in this regards.
Thanks.

These should cast the tBSP430periphHandle directly to the appropriate HPL volatile structure pointer.

May need to address #7 since the input is sometimes available on multiple pins.

No device-specific memory has been identified for this (no calibration constants, no TLV section) so the same EUI64 is generated for all parts.

On exp430fr5739 and trxeb if vBSP430lpmConfigurePortsForLPM_ni() is invoked before vBSP430platformInitialize_ni() the UART is unstable for the first several characters.

All current uses of xBSP430hplLookupFOO and hBSP430fooLookup use compile-time constant peripheral handles as the arguments. There is a great value in using peripheral handles in header files as the abstraction of a resource, and the code will be optimized if the translation from the handle to the HPL and HAL pointers can be resolved at compile-time. The cost of doing this is a creep of complexity into the headers, and a potential for redundant code should the function not be inlinable in multiple source modules.

As discussed in #19, allow for ACLK based on a clock that exceeds 64 kiHz.

The current system defaults to REFOCLK, which can be off by 2%. It should instead default to use XT1CLK for FLLREFCLK, which will fall back to REFOCLK when XT1 is faulted. For trimming it should use XT1CLK if stable, and never attempt to enable it internally.

It's nice that one has a shared buffer, but having to disable interrupts just to format a saved timestamp is unreasonable.

When using SPI with a logic analyzer it's nice to enable a pullup/pulldown on SCLK so the initial state is what the analyzer expects. Need a way to get the port and pin for a specific function like SCLK given the peripheral handle like BSP430_USCI5_B0.

Also consider enabling all peripheral HPLs by default instead of having to request them; since they're pointers to register maps there should be no impact other than the size of the functions that translate between peripheral handles and hpl handles, and those should be inlined or called rarely.

Should not be restricted to DCOCLDIV with divisor. At least XT2CLK should be an option.

RX/TX may bypass a check for error conditions; ensure loops are do/while rather than while.

Similar to what's done for LFXT1.

Enhance #31 by providing a macro/inline function for use when it is known the clock is synchronous with mclk, and using that in the safe-read interface when no CCIDX is provided.

See reproducing case at https://sourceforge.net/p/mspgcc/bugs/341/.

The uptime delay infrastructure wants global GIE clear on interrupts to ensure subsequent interrupts aren't processed after wakeup; this causes trouble when an application needs to have interrupts enabled for normal operation in active mode. Add support for this but with an optional warning that events could be dropped.

How can one move the user program to act as a bootloader and then do the firmware upgrade using either of the peripheral interfaces.?

-- Next how to disable loading default ldscript from mspgcc and have a customized ldscript.

Thanks in advance...

Using configFOO is stable when FOO is a constant feature like PORT1 or TB0. When a functional resource may select from among instances of a core resource class like timers or ports, the current solution with USE_DEFAULT_RESOURCE is messy and confusing. Rework this so that platform-default functional resources can be defined, the underlying core resources can be requested without reference to their specifics, and applications can override the platform settings without having to duplicate the configuration request infrastructure.

Contiki wants to be able to set the epoch for a timer (the clock_set_seconds() function). To avoid problems when the counter wraps this needs to be done in the HAL timer structure.

Enhancements/Feature Request:

• Can we have a microsecond timer support in the msp430 library.
• RTC/Timer library.
• Similar to tinyos can we have a oneshot timer/alarm support.

Currently USCI_A does not configure STE; USCI_B configures all four pins but only needs all four for a specific SPI mode. Should iBSP430platformConfigurePeriph_ni() take a second option that specifies how this should be done? What if the peripheral functions are available on multiple pin configurations?

Revision 1.073 of the TI msp430 headers no longer marks when a CS_A peripheral is being used. The differences between behavior and interface remain present. Come up with an alternative to MSP430_HAS_CS_A which is now MSP430_HAS_CS regardless of whether the MCU has the 57xx or 59xx version of the CS peripheral.

The hold/release USCI5 infrastructure operates on ctlw0 while the code that infers the proper peripheral configuration expects to be given a ctl0 value. The result is that the wrong bits are tested.