Jump to content

M-atthias

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    6
  1. Dear TI geeks, Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble. Matthias LDMIA and some other opcodes with a register list can be interrupted and continued afterwards in M3 and M4 cores. Unfortunately, there seems to be a silicon bug in some chips / core revisions that causes an interrupted LDMIA opcode to fail. The error has already been observed in LM4F120, TM4C1294, STM32F407 when using the multitasking example. M0 chips and EFM32GG990 are fine. It could affect other M4 chips and maybe M3, too. So if you get mysterious crashes when using Interrupts on M3/M4, try disabling preemption capabilities with this workaround: 1 $E000E008 ! Drawback is that this increases interrupt latency. Manual snipplets: B1.5.10 Exceptions in LDM and STM operations In order to allow implementations to have the best possible interrupt response, an interrupt can be taken during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is IMPLEMENTATION DEFINED. The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM, STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base register writeback update) during execution. M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html Address Name Type Required privilege Reset value Description 0xE000E008 ACTLR RW Privileged 0x00000000 Auxiliary Control Register Auxiliary Control Register [0] DISMCYCINT Disables interruption of multi-cycle instructions. This increases the interrupt latency of the processor because load/store and multiply/divide operations complete before interrupt stacking occurs. M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html Does not have this bit.
  2. Mecrisp is a native code Forth for MSP430 cores and Mecrisp-Stellaris runs on ARM Cortex M0, M3, M4. Forth is a programming language with two stacks and an extendable compiler which has been designed decades ago for controlling a radio telescope in astronomy and shows its strengths in microcontrollers, too. Its most interesting feature for embedded programming is that the compiler runs inside of the microcontroller and you basically chat with it over a serial terminal line or any other link you can imagine and implement. You can wiggle your wires manually, experiment with fresh peripherals and try every definition you wrote immediately. No need for the "change, assemble, flash and try" cycle. Great for hardware debugging ! Here is "the" classic Forth primer if you wish to get an idea how language looks like: http://www.forth.com/starting-forthTraditionally, Forth has been implemented with a virtual machine, but both my compilers generate native machine code for speed. Matthias
  3. I wish you happy Easter, of course with a small surprise: I just conquered the MSP432P401R with Mecrisp-Stellaris and I wish to announce quite fresh ports of Mecrisp for MSP430FR4133, MSP430FR5969 and MSP430F5529. Enjoy :-) Matthias
  4. Main Clock tree in section 5.2.5.2 shows a direct PIOSC line to the ADC CS, just as expected. Finally, section 15.3.2.7 gives an hint: 16 MHz PIOSC. Using the PIOSC provides a conversion rate near 1 Msps. To use the PIOSC to clock the ADC, first power up the PLL and then enable the PIOSC in the CS bit field in the ADCCC register, then disable the PLL. Stange procedure, but now it finally works. Thank you for pointing me to the right section ! Next release of Mecrisp-Stellaris will finally include an ADC example. PS: Mecrisp-Stellaris is written in bare metal assembly and not compatible with the C calling conventions, so I cannot hook the driverlib into.
  5. In section 15.4 "Initialisation and Configuration" of chip datasheet nothing is said about the need to set clock registers. But I tried nonetheless: #define ADC_CLOCK_RATE_FULL 0x00000070 #define ADC_CLOCK_RATE_HALF 0x00000050 #define ADC_CLOCK_RATE_FOURTH 0x00000030 #define ADC_CLOCK_RATE_EIGHTH 0x00000010 #define ADC_CLOCK_SRC_PLL 0x00000000 #define ADC_CLOCK_SRC_PIOSC 0x00000001 #define ADC_CLOCK_SRC_ALTCLK 0x00000001 #define ADC_CLOCK_SRC_MOSC 0x00000002 #define ADC_CC_CS_M 0x0000000F // ADC Clock Source ADCClockConfigSet(ADC0_BASE, ADC_CLOCK_SRC_PIOSC | ADC_CLOCK_RATE_FULL, 1); ADCClockConfigSet(uint32_t ui32Base, uint32_t ui32Config, uint32_t ui32ClockDiv) 0x00000001 0x00000070 1 // // Write the sample conversion rate. // HWREG(ui32Base + ADC_O_PC) = (ui32Config >> 4) & ADC_PC_SR_M; 7 ADC0_PC ! // // Write the clock select and divider. // HWREG(ui32Base + ADC_O_CC) = (ui32Config & ADC_CC_CS_M) | (((ui32ClockDiv - 1) << ADC_CC_CLKDIV_S)) ; 1 | 0 << ... = 1. 1 ADC0_CC ! Evaluating this gives exactly the reset-default values for CC and PC. Setting those registers to their reset value again does not change the problem: $400FE638 constant RCGCADC : init-analog ( -- ) $1 RCGCADC ! \ Provide clock to AD-Converter \ PIOs already activated in Core 50 0 do loop \ Wait a bit ; $40038000 constant ADC0_ACTSS $40038044 constant ADC0_SSCTL0 $40038028 constant ADC0_PSSI $40038048 constant ADC0_SSFIFO0 $40038FC4 constant ADC0_PC $40038FC8 constant ADC0_CC : temperature ( -- Measurement ) 1 ADC0_CC ! \ ALTCLK = PIOSC, divide by 1 7 ADC0_PC ! \ Full sample rate 0 ADC0_ACTSS ! \ Disable Sample Sequencers $A ADC0_SSCTL0 ! \ First Sample is from Temperature Sensor and End of Sequence 1 ADC0_ACTSS ! \ Enable Sample Sequencer 0 1 ADC0_PSSI ! \ Initiate sampling begin $10000 ADC0_ACTSS bit@ not until \ Check busy Flag for ADC ADC0_SSFIFO0 @ \ Fetch measurement result ; init-analog temperature .
  6. This is all my hardware startup code accompanying the example above. All other IO registers are on Reset default. movw r1, #0x7FFF @ Activate clock for all GPIOs ldr r0, =RCGCPIO str r1, [r0] movs r1, #1 @ Activate clock for UART0 ldr r0, =RCGCUART str r1, [r0] movs r1, #0x11 @ Set special function for PA0 and PA1 ldr r0, =GPIO_PORTA_AHB_PCTL_R str r1, [r0] movs r1, #3 @ Set special function for PA0 and PA1 ldr r0, =GPIO_PORTA_AHB_AFSEL_R str r1, [r0] @ movs r1, #3 @ Set special function for PA0 and PA1 ldr r0, =GPIO_PORTA_AHB_DEN_R str r1, [r0] movs r1, #0 @ UART stop ldr r0, =UARTCTL str r1, [r0] @ Baud rate generation: @ 16000000 / (16 * 115200 ) = 1000000 / 115200 = 8.6805 @ 0.6805... * 64 = 43.5 ~ 44 @ use 8 and 44 movs r1, #8 ldr r0, =UARTIBRD str r1, [r0] movs r1, #44 ldr r0, =UARTFBRD str r1, [r0] movs r1, #0x60|0x10 @ 8N1, enable FIFOs ! ldr r0, =UARTLCRH str r1, [r0] movs r1, #5 @ Choose ALTCLKCFG = PIOSC (default) as source ldr r0, =UARTCC str r1, [r0] movs r1, #0 ldr r0, =UARTFR str r1, [r0] movw r1, #0x301 @ UART start ldr r0, =UARTCTL str r1, [r0]
  7. Clock source for this failing example is 16 MHz PIOSC, which is default for ALTCLKCFG, which is default for ADC clock on TM4C1294. I already checked for those 16 MHz by generating an interrupt driven square wave with Systick timer. PLL and MOSC XTAL are off, UART0 is running on PIOSC, too. Tivaware examples unfortunately are of limited help for me as the calls diffuse within a huge library - I already banged my head against the adc.c in driverlibs. Do you know "direct register" examples for TM4C1294 ? Matthias BTW, off-topic: I found out that the simple ethernet transmit descriptors are non-functional, a silicon bug circumvented in Tivaware library by always enabling the advanced descriptor format for transmit packets, but this is not documented in chip errata. For this reason I got suspicious.
  8. Dear Stellaris geeks, I am porting code from LM4F120 Stellaris Launchpad to TM4C1294 Tiva Connected Launchpad. I found the literature SPMA065 "Differences Between Tiva C Series TM4C Microcontrollers" which states that analog-digital converters in TM4C1294 only add features relative to TM4C123 / LM4F120. But I cannot make my ADC code work. To nail it down I have done this minimal example code in Forth (Mecrisp-Stellaris 1.1.5): $400FE638 constant RCGCADC : init-analog ( -- ) $1 RCGCADC ! \ Provide clock to AD-Converter \ PIOs already activated in Core 50 0 do loop \ Wait a bit ; $40038000 constant ADC0_ACTSS $40038044 constant ADC0_SSCTL0 $40038028 constant ADC0_PSSI $40038048 constant ADC0_SSFIFO0 : temperature ( -- Measurement ) 0 ADC0_ACTSS ! \ Disable Sample Sequencers $A ADC0_SSCTL0 ! \ First Sample is from Temperature Sensor and End of Sequence 1 ADC0_ACTSS ! \ Enable Sample Sequencer 0 1 ADC0_PSSI ! \ Initiate sampling begin $10000 ADC0_ACTSS bit@ not until \ Check busy Flag for ADC ADC0_SSFIFO0 @ \ Fetch measurement result ; init-analog temperature . This runs fine on LM4F120, but it hangs in busy loop on TM4C1294. Further research shows that ACTSS busy flag is never cleared again, this register always reads $00010001 after setting the bit in PSSI register (it is $00000001 before setting PSSI bit). This behaviour happens to all other analog input channels, too, but temperature sensor gives shortest code. Setting SSCTL0 Interrupt Enable together with Temperature and End of Sequence flag doesn't generate a bit in RIS register either. I am puzzled, perhaps this is a silicon bug undocumented in current chip errata ? Did I miss something, or does someone know a workaround ? Best wishes, Matthias
  9. Frequency accuracy depends on how far off your crystal is. The closer the crystal matches the frequency, the finer the available calibration steps are. On my STM32F407 Discovery, the crystal is 74ppm too fast. Besides from this, the simple convolution receiver code included has 1 us time steps, but could changed for more precision at cost of more calculation time. eLoran enhancements are currently not included in first release :-) This is a basic old-style Loran-C receiver to be build with a common STM32F407 board and a longwave antenna. For eLoran all-in-sight recording we would need (much) more RAM. Currently, I wish for testing, and if basic receiver code proves to work well, I will continue to try automatic initial coarse crystal frequency determination out of Loran signal itself and on-the-fly clock re-adjustments. Thank you for the hint with the time-nuts list ! Perhaps you could introduce me there ? Copy from README of Loran-C package: Timer 2 gets 60 MHz clock signal and triggers * every 60 clock cycles (exact-xtal) * every 60 or sometimes 61 clock cycles (fast-xtal) * every 60 or sometimes 59 clock cycles (slow-xtal) Timing of captures in Timer ticks @ ~60 MHz: | 60 | 60 | 60 | 60 | 60 | 60 | ... Theoretical f = 1 MHz With Switch-cycles: Tack=1: | 60 +- 1 | 60 +- 1 | 60 +- 1 | 60 +- 1 | 60 +- 1 | 60 +- 1 |... Tack=2: | 60 | 60 +- 1 | 60 | 60 +- 1 | 60 | 60 +- 1 |... Tack=3: | 60 | 60 | 60 +- 1 | 60 | 60 | 60 +- 1 |... ... Frequency is theoretically given by f = q / (1 +- (1/60*tack)) f : Frequency on orange LED q : Free-running frequency of crystal through PLL <=> tack = 60 / (q/f - 1) Some examples: Offset: Free frequency 0 ppm: 1 000 000 Hz Tack infinite, use exact-xtal handler 1 ppm: 1 000 001 Hz Tack 16666 10 ppm: 1 000 010 Hz Tack 1666 20 ppm: 1 000 020 Hz Tack 833 50 ppm: 1 000 050 Hz Tack 333 80 ppm: 1 000 080 Hz Tack 208 100 ppm: 1 000 010 Hz Tack 166 The more far off the crystal is, the more coarse the Tack steps will be. Useful Tack range will be around 150 to 20000... Some measurements with my particular crystal: # Tack Frequency [kHz] determined with frequency counter # 0 983.682 # 1 983.682 # Every cycle is a switch cycle 2 991.812 3 994.551 4 995.927 5 996.754 6 997.306 7 997.701 8 997.997 9 998.228 10 998.413 11 998.563 12 998.690 13 998.796 14 998.887 15 998.966 20 999.244 30 999.521 40 999.656 50 999.744 60 999.799 70 999.838 80 999.868 90 999.891 100 999.909 150 999.965 200 999.993 # Useful range begin 250 1000.010 # end for this particular crystal 300 1000.020 400 1000.034 500 1000.043 # 30000 1000.076 # Almost without switch-cycles, close to free running crystal frequency Useful ranges are roughly from 150 (bad crystal, 100ppm offset) to 30000 (0.3ppm crystal offset).
  10. Happy new year ! Loran-C radio navigation now runs on STM32F407 - thank you for the hint. As this will be a bit off-topic here I announced it on Stellarisiti: http://forum.stellarisiti.com/topic/1807-loran-c-radio-navigation/ Matthias
  11. Happy new year ! I am happy to announce a software defined Loran-C longwave radio navigation receiver running on STM32F407 ! If you happen to live somewhere on earth with Loran-C signal coverage like Europe and parts of Asia, I would like to get in contact with you for beta testing out in the wild. The first experimental release is available now on download section on http://mecrisp.sourceforge.net/ Best wishes, Matthias
  12. I just discovered the above Boot430 implementation out into the wild :-) Great ! http://programmablehardware.blogspot.de/2013/11/homebrew-msp430-development-board.html Best wishes, Matthias
  13. I have done a similiar experiment while writing Mecrimus-B. I adjusted DCO settings manually with a frequency counter and connected to USB. My observation was that I could break the connection due to DCO frequency change by touching the chip with a warm finger or by breathing against it.
  14. Good morning to Italy - I like your project a lot ! Mecrimus-B already defines a mouse, it is constantly moving the pointer to the right, but adding buttons should be simple if you feel comfortable with assembly. Replace this sequence in Mecrimus-B-32768Hz.asm with button states - movements are 8-bit signed integers, moving to the left would be -1=255: mov.b #0, &Irq_In_Sendepaketpuffer+2 ; Buttons pressed mov.b #1, &Irq_In_Sendepaketpuffer+3 ; X movement mov.b #0, &Irq_In_Sendepaketpuffer+4 ; Y movement mov.b #0, &Irq_In_Sendepaketpuffer+5 ; Wheel movement Replace toggle_syncled with a 4 cycle nop, remove the clockout init code and change the PxDIR settings accordingly after Reset, and the debug signals are gone. toggle_syncled macro ; Preserve clock cycles if you want to remove this ! xor.b #4, &P1OUT ; Toggles Sync LED, good for triggering an oscilloscope and visual feedback endm toggle_syncled macro ; Preserve clock cycles if you want to remove this ! nop2 nop2 endm Remove this: bis.b #010h, &P1SEL ; SMCLK an P1.4 ausgeben SMCLK for measurements on P1.4 Boot430 includes a lot of special code not needed for a mouse, and note that the bbusb package still contains a serious bug in its receiver code inherited from early Mecrimus-B, as this has been mostly a development shapshot. @@simpleavr Maybe you could repackage bbusb as a simple C starting point and replace the receiver with the Boot430's one which has the SE0-unstuff-bug fixed ? I understand that you are puzzled by now. USB support on MSP430 is still in an early stage, Boot430 is the first application and the most current piece which development is focussed on. Boot430 is based on the bbusb snapshots, and bbusb is an enhanced and improved C rewrite of Mecrimus-B, which is assembler only. I fixed all known bugs in Mecrimus-B, but it is a pioneer, and it has not received so much testing effort, high-level protocol support and functionality enhancements. Altough it will be possible in future, you have no choice but to use the 32768 Hz crystal for long-time stability at the moment. Mecrimus-B offers direct input of stable digital external 15 MHz or 18 MHz clock, but this is not what you search for. For a prototype, you can drop ESD protection, look at the pictures of my early msp430f2012 board and simpleavr's breadboard clone at the beginning of this thread to get an idea what is needed for a start. Best wishes for your project from Germany, Matthias
  15. Fine, one more issue solved. Yes, toggle_syncled can be replaced by a 4 cycle nop.
×
×
  • Create New...