Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


SmokinGrunts last won the day on June 16 2016

SmokinGrunts had the most liked content!

About SmokinGrunts

  • Rank
  1. Def. interested in ~10 of these, if they ever pop-up again.
  2. After much finagling and testing with Rick, he discovered that the Stack Pointer register is fuxxed. Here's CCSv6 and Energia 17, Working: http://i.imgur.com/A5n3gzb.jpg Here's CCSv7 and Energia 18, Not working: http://i.imgur.com/Vt4yh2y.jpg Breadcrumbs... If anyone runs into this and needs more help, let me know.
  3. Aye I'll hop on IRC, just got my system reloaded
  4. Much obliged, thanks Rick! I'll give this a go in a bit, report back here. Note that I'm able to successfully debug in CCS through a very annoying workaround... By turning off auto-run in the debug options, loading the program, and performing a manual system reset from the debug toolbar...
  5. Here's a thread, circa 2014, describing a workaround for this issue: (scroll to top of page, link is to my latest post in the thread) https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/363076/2152558#2152558 The linked thread describes a problem and solution for CCSv6, almost identical to the CCSv7 behavior I'm seeing. I don't understand why 1- I never had this issue before, with the same version in the link, and 2- why CCSv7 would have this behavior... Thoughts?
  6. Here's the exact screenshot of what happens once I single-step into ResetISR()
  7. Hello all! So, this is happening on BOTH my Ubuntu 16.04 AND Windows 8.1 systems. This is for a TM4C1294NCPDT. To reduce potential variables, I've reverted to using the EK-TM4C1294XL Development Board. To reproduce: Fresh install of CCSv7.1, Fresh install of Energia 18. Open CCSv7, Create a new workspace, select 'Project > New Energia Sketch', Energia Version set to 18, select 'Built-in Examples > 01.Basics > Blink.ino', selected device: 'LaunchPad (Tiva C) w/ tm4c129 (120MHz), select 'Finish'. Right Click 'Blink" project in the Project Explorer, select "Build Project'. Project builds fine. Push F11 (or select 'Debug Blink' from the toolbar). Code is uploaded, but the debug 'Resume' button is grayed out. LED does not blink. Note: 'Blink' runs fine in the Energia IDE itself. What happened in the update to CCSv7? I'm taking a shot in the dark here, but I think the memory map is b0rked. If I disable "On a program load or restart" in the 'Debug > Auto Run and Launch Options' and then attempt to debug, CCS starts the debugger at "void ResetISR(void) {" in startup_gcc.c. See attached image for disassembly view. I think (IIRC) that the two ldr calls in assembly are usually right below that 'push', but my memory ain't what it used to be. Anyhow, if I try to 'Step Into' with F5, I immediately get a dreaded "No source available for "0xfffffffe" ... So, any idea what the hell happened? This shoots me dead until this is resolved... I figured TI would at least test Energia GCC debugging before releasing v7, though I do tend to err with my assumptions quite often. If you need anything, just holler. EDIT: For posterity, here's my TI E2E forum post on the same: https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/586137
  8. Depends on how fast you're running the core clock. Example: For a clock frequency of 120 MHz, (120,000,000 Hz) it will take 120,000,000 'ticks' to elapse 1 second of real world time. All you're doing with WatchdogReloadSet(WATCHDOG0_BASE, MAP_SysCtlClockGet() * 2); is setting the load value of the watchdog timer, which runs at the system clock frequency. A watchdog is geared more towards recovery from catastrophic failure in embedded systems. I would recommend using a software reset for as many cases as you can muster. Otherwise, you could set up a basic timing system like the following: (Note that I use floating point on my Tiva 'cuz... Well why not! Haven't run into memory issues yet...) volatile uint32_t AppStartTime; // Application Start time in microseconds volatile uint32_t AppEndTime; // Application End time in microseconds volatile uint32_t AppRuntime; // Application Run time in microseconds // Take Application Start Time (Whenever you feel is necessary, you could do it in setup() or loop() if you wanted) AppStartTime = millis(); // Blah blah program code here ... // Take Application End Time AppEndTime = millis(); // Buffer for snprintf char ptimeBuf[6]; // Calc Run Time AppRuntime = AppEndTime - AppStartTime; // Convert to Seconds float32_t AppRuntimeSecs = AppRuntime / 1000.0; // Parse Float into Char Buffer snprintf(ptimeBuf, 6, "%.2f", AppRuntimeSecs); // This is a custom wrapper I made combining Serial.print() and UARTprintf() functionality... And then some. // Probably just use UARTprintf() in place of term.println() // Also note the ANSI terminal escape codes. I like coloring output. I set up some eclipse hotkeys to make for // some groovy/easy function timing. Colors really help with tons of output. term.println("Complete Program Time (Main Loop Entry -> Finish: \e[38;5;220;1;4m%s Seconds\033[m", ptimeBuf); Anyhow, if your entire application takes for instance an average of 30 seconds, and the code is frozen, why not set the watchdog at something like 1 min. 30 secs?
  9. Seeing this by googling "energia" and clicking the link for energia.nu; I get the hacked page. When I type www.energia.nu in a new tab, it loads fine. I've cleared cache, used a fresh machine, etc. Hope this helps.
  10. Welp, the ONE TIME I don't perform my due diligence in searching... Just found this: http://forum.43oh.com/topic/9238-timer-pin-interrupts-for-tiva/?hl=timer Going to try it. I got noobsauce all over me it appears.
  11. Hey all! Finicky issue, and I've been up for way too many hours so I'm breaking from usual habit and posting after only doing minimal digging. Hopefully it's a simple solution. Fingers crossed. Board: TM4C1294NCPDT IDE: CCSv6.1 OS: Ubuntu 16.04 Compiler: GNU v4.9.3 (Linaro) So here's what's up: I'm versed using timers and setting up my vector table properly, or so I thought. Code Composer Studio isn't finding my interrupt handler... It's confuzzling me to say the least... Here's what I'm doing: In startup_gcc.c //......Skipping top of file for readability, all is stock // External declarations for the interrupt handlers used by the application. extern void Timer1AIntHandler(void); //......Skipping a bunch of nonsense for readabilities sake //Beginning of vector table (NOT Blizzard, but Snowflake/RA0) #else __attribute__ ((section(".isr_vector"))) void (* const g_pfnVectors[])(void) = { (void *)&_estack, // The initial stack pointer ResetISR, // The reset handler NmiSR, // The NMI handler FaultISR, // The hard fault handler IntDefaultHandler, // The MPU fault handler IntDefaultHandler, // The bus fault handler IntDefaultHandler, // The usage fault handler 0, // Reserved 0, // Reserved 0, // Reserved 0, // Reserved IntDefaultHandler, // SVCall handler IntDefaultHandler, // Debug monitor handler 0, // Reserved IntDefaultHandler, // The PendSV handler SysTickIntHandler, // The SysTick handler GPIOAIntHandler, // GPIO Port A GPIOBIntHandler, // GPIO Port B GPIOCIntHandler, // GPIO Port C GPIODIntHandler, // GPIO Port D GPIOEIntHandler, // GPIO Port E UARTStdioIntHandler, // For UARTStdio - UART0 Rx and Tx UARTIntHandler1, // UART1 Rx and Tx IntDefaultHandler, // SSI0 Rx and Tx IntDefaultHandler, // I2C0 Master and Slave IntDefaultHandler, // PWM Fault IntDefaultHandler, // PWM Generator 0 IntDefaultHandler, // PWM Generator 1 IntDefaultHandler, // PWM Generator 2 IntDefaultHandler, // Quadrature Encoder 0 ADC0IntHandler, // ADC Sequence 0 IntDefaultHandler, // ADC Sequence 1 IntDefaultHandler, // ADC Sequence 2 IntDefaultHandler, // ADC Sequence 3 IntDefaultHandler, // Watchdog timer IntDefaultHandler, // Timer 0 subtimer A IntDefaultHandler, // Timer 0 subtimer B Timer1AIntHandler, // Timer 1 subtimer A (Thar she blows...) And then in my main project file: // Only showing relevant pieces... // // Prototypes // ========== // Bunch of skipped out-of-scope stuff... void init_Timer(void); void Timer1AIntHandler(void); void init_Timer(void) { // Enable interrupts to the processor. ROM_IntMasterEnable(); // Enable Timer Peripheral ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_TIMER1); // Configure Timer1 to be Periodic, with a 100Hz interrupt ROM_TimerConfigure(TIMER1_BASE, TIMER_CFG_PERIODIC); ROM_TimerLoadSet(TIMER1_BASE, TIMER_A, g_ui32SysClock / 100); // Setup the interrupts for Timer1 timeout. ROM_IntEnable(INT_TIMER1A); ROM_TimerIntEnable(TIMER1_BASE, TIMER_TIMA_TIMEOUT); // Enable Timer1A. ROM_TimerEnable(TIMER1_BASE, TIMER_A); } // void loop() is there somewhere, but it's HUGE, doesn't use the timer anyway. void Timer1AIntHandler(void) { // Clear the timer interrupt. ROM_TimerIntClear(TIMER1_BASE, TIMER_TIMA_TIMEOUT); // Call the FatFs tick timer. disk_timerproc(); } I need the timer for FatFS by ChaN. CCS gives me this on building (skipped everything until the linker output): Sooo what's going on here? Does the Energia part of CCS do something different with the timer section of the vector table? I have a custom ADC0IntHandler which works just fine... If anyone needs more info, I'm more than glad to provide it. Frustrations abound, and it especially sucks 'cuz after a 20 hour coding marathon, a problem like this is just... Awful.
  12. Beware! TM4C1294NCPDT has only one pin that is 5V tolerant: PB1 ( USB0VBUS ) Via: http://www.ti.com/lit/ds/symlink/tm4c1294ncpdt.pdf#page=1851 (Page 1851 of the datasheet) Edit: Annnd that's what I get for not reading the whole thread. Beaten to it!
  13. If you're ready to move beyond the Arduino-esque IDE that is Energia, but still want to make use of the easy-to-read Energia Libraries, I'd recommend setting up something like Code Composer Studio (really just Texas Instrument's re-branded version of Eclipse) and getting to know the GNU GCC toolchain. The latest version of CCS just came out, has Energia sketch/library support built in, and has a number of other great features. I haven't used the Energia IDE for some time, but I do attempt to maintain using the libraries. So, I can't give you the answer you're looking for, but if you do decide to make the switch, all output files for CCS are generated in your project's 'Debug' folder. There is a learning curve, but the experience is worth having under your belt if you are serious about programming.
  14. Correct, uint8_t WiFiClass::encryptionType() and uint8_t WiFiClass::encryptionType(uint8_t networkItem) Two functions, with the same name, but different parameters. This is called Function Overloading. Your compiler determines the best fit for which function definition to process based on the types you give to said function. For more information, see here: http://www.tutorialspoint.com/cplusplus/cpp_overloading.htm
  15. Gotta see more code to really know what's going on. Do you have your UDP object properly initialized? something like: do { // Detect if we've started the UDP server Serial.print("."); // print dots while we wait delay(300); } while(!BroadcastSendUDP.begin(localPort)); Notice that BroadcastSendUDP.beginPacket() will *not* get a socket and bind it to a port for you, you must call begin() first. Relevant snippet for reference: int WiFiUDP::beginPacket(IPAddress ip, uint16_t port) { // //make sure a port has been created //!! this doesn't create a port if one doesn't exist. Is that ok? <--------- Look here // if (_socketIndex == NO_SOCKET_AVAIL) { return 0; } ...
  • Create New...