JRDavisUF

Members
  • Content count

    14
  • Joined

  • Last visited

  • Days Won

    2

JRDavisUF last won the day on March 28

JRDavisUF had the most liked content!

About JRDavisUF

  • Rank
    Member
  1. Discovered a bug in my code, so for completeness, below are the updating timing numbers: 9 byte string 9 byte array 64 byte structure pyCrc 13us 13us 57us** driverlib software Crc* 11us 10us 49us rom Crc 15us 15us 79us *driverlib software includes a 1us delay to ensure enough time to process results. ** this is the value which was wrong in previous post....pyCyc isn't twice the speed of the driverlib version. they are actually comparable.
  2. OK, I think I get it now. I new the rom_map.h header selected the hardware or software version, but I really didn't look into what it was doing. I was assuming it determined whether or not my rom could support it. Turns out, one must include the rom header before the rom_map header. If I do that (or replace MAP_ with ROM_), I don't need any delays to get it to work correctly....So I think Clavier is spot on. The flip side is that the rom version is significantly slower than the software versions. So I guess the price one is paying for a reduced code size, is speed? I guess I get that. 9/10 bytes 66 bytes pyCrc 13us 13us driverlib software Crc 11us 27us rom Crc 16us 74us
  3. Thanks for the ideas. Energia uses the WDT for other purposes, as such I didn't put it in my code. However, I just stuck it in and that doesn't help. I did try getting rid of the MAP_ stuff and that didn't help either. I also noticed that the example defined the returned crc value as volatile, so I changed that, but it didn't help either. I missed the 1-clock cycle note. As such, I changed my 1 microsecond delay to a 1 cycle delay and the code works fine. I'm guessing that must be the issue.
  4. FWIW, I did figure out why my RTC clock accuracy was so bad. By default, the RTC clock sources the internal 32k crystal, not the external LFXT as BCLK. As such, to get it to work: 1) Define frequency of LFXT to 32k: MAP_CS_setExternalClockSourceFrequency(32768, 48000000); // LF, HF (why energia doesn't do this already, I don't know. I see how starting it might consume power unnecessarily, but why not set the value atleast???) This step might not be needed, but since I wanted to query my clock speeds later, I added it. 2) Turn on LFXT (I loop on this since it doesn't always take): bool status = MAP_CS_startLFXTWithTimeout(CS_LFXT_DRIVE3, 10); 3) Tell the RTC to use LFXT: MAP_CS_initClockSignal(CS_BCLK,CS_LFXTCLK_SELECT,CS_CLOCK_DIVIDER_1); With my msp432 launchpad, this gives me about 5ppm (testing every 15s for about 2 weeks). Hope this helps anyone else who might have had issues... jrd PS Of course, you probably don't need to use the MAP_ versions...but I figured why not PPS This is how I was getting my actual clock speeds...ie, why I added step 1. // Get the values uint32_t aclk = MAP_CS_getACLK(); uint32_t mclk = MAP_CS_getMCLK(); uint32_t smclk = MAP_CS_getSMCLK(); uint32_t hsmclk = MAP_CS_getHSMCLK(); uint32_t bclk = MAP_CS_getBCLK();
  5. win10 - ccsv7 - energia 18 - msp432 launchpad I'm trying to use the crc32 library from driverlib to do a simple crc-16-ccitt calculation and stumbled across a weird problem. Just to give a quick background, the way the crc32 library works is the following: 1) initialize 2) add N bytes to be processed 3) request the computation to be done In order to get the routine to work correctly, I must slow down the code with some additional code in between steps 2 and 3. This can be operations, Serial.print, or even just a simple 1 us delay. If I do not do this, the answer I get is equal to the crc checksum of just the N-1 bytes (dumb luck figuring this out). So it kind of looks like the last byte is not getting added fast enough before the request to perform the crc is being made. Anyone run across this? I've not seen it mentioned anywhere. Example code attached. This code will repeatedly try and perform a crc until it fails. When it does fail, it pauses briefly and then reboots. Currently, it fails instantly for me...but if I add it some timing operations between 2 and 3, for example, it will fail at a seemingly random attempt number. If you un-comment the 1 us delay, it will run successfully. Although I've not tested yet, I'm wondering if I will see the same issue appear with the aes256 stuff as well since it looks like its implemented in a similar way. thx. jrd PS CRC-CCITT (0x1D0F) calculation has been verified a software implementation I haveas well as the value that is calculated here: https://www.lammertbies.nl/comm/info/crc-calculation.html code.ino
  6. Thanks! Switching to the Hwi stuff to register the interrupt (and adding arguments into the ISR) was exactly what I needed. RTC + WiFi now works fine...Now if I can just figure out why my RTC clock accuracy is only 3000ppm ...
  7. Ok, I've now done that: https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/567067
  8. Still trying to figure this out. I output the hw/sw versions, do these look correct: H/W and S/W Versions CHIP: 67108864 MAC: 31.1.4.0.1 PHY: 1.0.3.34 NWP: 2.7.0.0 ROM: 13107 HOST: 1.0.0.10
  9. Oh ya, a couple other things I tried: 1) I disabled the RTC alarm and unregistered the interrupt immediately after I set it. If I do that, the WiFi still will not start. So registering the interrupt seems to foo-bar something. 2) I ran the RTC_C demo code from the driverlib example code that I found within the resource explorer (MSP432ware). That stuff compiled and seemed to run fine.. I do note that the example code does not use a function call to register the interrupt for the RTC_C alarm like I am doing. They have some "startup" code which explicitly defines the list of all the interrupts. Does energia have this somewhere? Perhaps my use of the interrupt register function is incompatible with startup-type code????
  10. Made some progress, but am still having the same problem. First, I tried this code with CCSv6.2/E17 and had the same problems. Second, I put a WiFi.begin/WiFi.disconnect in front of the RTC stuff in addition to after the RTC stuff....and this allowed the WiFi to start after the RTC stuff had been called. So it seems happier letting the WiFi stuff go first....*However*, I really need more than a WiFi.disconnect, for power consumption purposes, I need to shutdown the WiFi module completely, as such I do a "sl_Stop(0)" This works great in terms of turning off the power to the wifi module (CC3100); however, when I do a WiFi.begin/WiFi.disconnect/sl_Stop before the RTC stuff, I can no longer re-start the WiFi after the RTC stuff again...So I'm sort of back to square one...
  11. OK, I got rid of the Serial stuff and used the green led to indicate success or failure. The code again hangs when attempting to start wifi. I then got rid of the the Wifi part and the code runs fine. As such the problem still seems to be some combination of RTC_C and WiFi
  12. I want the device to wake up once an hour, stream some data and then go back to sleep...So, I DO want the login to be inside a loop. For purposes of this issue, it doesn't matter though...all commands can be in the setup, all in the loop, or a mixture...regardless, the same problem occurs. For the code I provided, I was just trying to minimize things to just the bare-bones level. In the real code, I have a simple handler *.ino loop which is waiting on an Event. When the calendar ISR get's triggered, all it does is send the Event which wakes up the handler loop which then starts/stops data collection depending on the time.
  13. Windows 7 / Code Composer Studio 7 / Energia 18 / MSP 432 LaunchPad + CC3100 WifI I'd like to use a RTC_C calendar alarm to turn on/off my some streaming data collection, however, it doesn't seem to work. That is, once I register the RTC_C interrupt via RTC_C_registerInterrupt, I'm unable to init the WifI. Specifically it hangs here in WiFi.cpp: int iRet = sl_Start(NULL, NULL, NULL); I've whittled my code down to what appears below. Does anyone have any ideas? jrd ----- // Header files #include <WiFi.h> // Energia #include <driverlib/MSP432P4xx/rtc_c.h> #ifndef cWiFiSSID cWiFiSSID should be #define as the name of your WiFi SSID #endif #ifndef cWiFiPassword cWiFiPassword should be #define as the name of your WiFi password #endif void vRtcIsr() { // Clear the flag, but don't actually do anything RTC_C_clearInterruptFlag(RTC_C_CLOCK_ALARM_INTERRUPT); } // Main setup section void setup() { // Turn on serial output Serial.begin(115200); Serial.println(""); // Enable the clock RTC_C_startClock(); // Set an alarm RTC_C_setCalendarAlarm( 0, RTC_C_ALARMCONDITION_OFF, RTC_C_ALARMCONDITION_OFF, RTC_C_ALARMCONDITION_OFF); RTC_C_registerInterrupt(vRtcIsr); RTC_C_enableInterrupt(RTC_C_CLOCK_ALARM_INTERRUPT); } // Main loop section void loop() { // Start WiFi Serial.println("Attempting to turn on Wifi"); WiFi.begin(cWiFiSSID,cWiFiPassword); Serial.println("Success"); // Hang forever for(;; }
  14. On a related note, A8=A9=27. I believe A9 should actually be 26. I'll also mention that although A2 cannot be used (even if you put the correct pin number in there) per Robert's comment, A9 can be used if you just use the value 26 instead of 27.