• Content count

  • Joined

  • Last visited

  • Days Won


JRDavisUF last won the day on July 23

JRDavisUF had the most liked content!

About JRDavisUF

  • Rank
  1. So I think I understand the SD problem. I amusing a non-ti-rtos way of accessing my SD card. My guess would be that the more ti-rtos-centric way of implementing things in the msp432 emt red libraries is conflicting with my non-ti-rtos sd card library. I was able to successfully install/compile the ti-rtos/fatsd example, so I know it's not a ccs/board/wiring/etc. issue. However, it's not entirely clear which direction I should head now. Should I try and get the fatsd example working under energia?, or does someone have an energia ti-rtos SD library already working with the msp432 emt red stuff?
  2. And another issue, my SD card is no longer able to be initialized. I created a new MSP432 sketch (not a red mspp one), copied my code over and the SD card initializes fine.
  3. One thing I'll mention though, is that the level of noise I'm seeing looks to be about double of what it was before. That is, for a "constant" voltage, I was seeing about 20 ADC units of RMS noise, while now I'm seeing 40 for my particular circuit with no other wiring/setup changes.
  4. OK, I went through all the steps and it still didn't work. The "wiring_analog.c" error is gone, but now its complaining about the random functions. I undid your step 2 (uncommented them again)....and now it seems ok.
  5. Yup, already found the ADC resolution stuff and have set it up as 14 bit. Is there any sort of guide anywhere on transitioning from the msp432 to msp432r emt red libraries? (in particular, I'm using CCSv71 on a Win10 machine) I've spent about 3-4 hours already trying to get my code to compile using the red version and haven't gotten anywhere. I've re-installed energia, re-installed the boards, wiped our my ccs workspace, etc. and am now upgrading to CCSv7.2. With everything cleaned out and new (except CCS 7.2), when I go to create a new energia sketch, it immediately tells me "wiring_analog.c already exists"...Then, if I make a simple wifi-enabled sketch (even an empty sketch won't compile), it won't compile. It brings in the _core and _WiFi libraries, but neither compile. Both give various errors relating to not being able to find SPI. If I build the _core and _WiFi libraries standalone (not through my sketch, but by themselves), they do compile. However, if I then try and build my simple sketch, CCS tries to re-build _core and _WiFi then they no longer compile. I assume something is wonky with my CCS, hence my current attempt at upgrading CCS.
  6. Yeah, sorry for being a little vague, I was trying not to be too specific because I'm still not exactly clear as to where my problems lie. I'm designing some IOT-based sensors for water level/waves. We've tested the pressure sensor and it's associated electronics and it seems to be functioning correctly. The pressure sensor itself is supposedly 0.05% accurate (which we can confirm by using a volt meter directly), but our calibrations (based on the ADC results out of the MSP432) are coming in at 2-3% accurate. The ADC "oddness" I've seen...some of which I've figured out answers to (e.g. blown boards) and some not...has manifested itself in a variety of ways: 0) ADC values which differ based on ADC clock used 1) Hysteresis of ADC results. ADC/Volts for increasing voltages (calibration of a pressure sensor) don't equal ADC/Volts for decreasing voltages 2) Bi-modal gaussian-looking distributions ADC values for a "constant" voltage..so a mean I calculate ends up being a value that isn't measured often. 3) For a "constant" voltage, distribution of ADC values which look Gausian, however, some ADC values within that shape are never recorded. For example, say I have a mean value of 1000. Then if I analyze a histogram of ADC values, I'd see something like: 2-996 values, 5,-997 values, 13-998 values, no-999, values, 200-1000 values, etc. 4) For a "constant" voltage, ADC means varying over time (tens of seconds to minutes) for a "constant" voltage 5) Peculiar oscillations of values. For example,for a specific "constant" voltage input, some (but not all) of the values go back and forth between 1650 and 1677. 1650 = b0110 0111 0010 1677 = b0110 1000 1101 what's weird is that the last 8-bits are exactly the opposite. I also have other combinations of numbers which seem to have their bits be exactly opposite. Maybe this is just a quirk, but it seemed strange. 6) ADC values which bounce back and forth between two values...with almost no values in-between recorded...so it kind of looks like a digital signal. I'm using external voltage references and I'm pretty sure I've blown out a few boards because of that. Some of blown boards which I can explain (taking samples with internal Vref configured but with external connected) and some I cannot. For example, my Verefs now are drawing 30 ma and I know that's wrong, but I'm definately setting up my analogRead's using external references by default now. So some of these issues kind of feel like I've blown out some bits on my ADC and some kind of feel like ADC clock/sample timing issues...hence when I was delving into the code to figure out how that stuff works at a low level. (I know I have more to learn in that regard and I'm by no means sure that my wiring, analog/sample filtering, grounding, etc. are completely correct yet so take this all with a grain of salt...) I started with the black, but pretty much am only using the red now....and you pointed out a good issue, I am using the MSP432 stuff, not MSP432 EMT RED. I don't think I ever noticed there were two different ones in the board manager. I know the board manager is new, I forget what I was doing for v17. I'll get that switched over ASAP and let you know if that helps. I've had some other kind of weird errors pop up every now then...maybe this will help with those issues too
  7. I'm trying to figuring out some oddness in the ADC conversions of my MSP432 Launchpad and I ran into something I don't quite understand. In Energina18 wiring_analog.c initializes ADC14 on the MSP432 with the following driverlib command: MAP_ADC14_initModule(ADC_CLOCKSOURCE_MCLK, ADC_PREDIVIDER_1, ADC_DIVIDER_1, 0); As expected, CS_getMCLK() is reporting that MCLK is running at 48 MHZ. So the clock being provided to the ADC14 is 48/1/1 or 48 MHz. However, my reading of the ADC14 datasheet/documentation states that ADC14 clock source is limited to 25 MHz (which, in theory, will give 1 Msps).. To see if this clock source was causing my original "oddness", I tried the following combinations of clocks and dividers: ADCOSC/1/1, MCLK/1/1, MCLK/1/2, MCLK/1/4, and MCLK/1/8. For a "constant" voltage to be converted, ADCOSC/1/1 (25 Mhz, I believe), MCLK/1/2 (24 MHz), MCLK/1/4 (12 MHz)and MCLK/1/8 (6 MHz) gave basically the same ADC value...while MCLK/1/1 gave something about 7.5% higher. Anyone run into this before? It seems like the clock might need to be divided by atleast 2...but maybe I'm missing something... jrd PS I'll also note that if I look at the examples in the ADC14 msp432 driverlib (3_21_00_05), five use MCLK/1/1 and two use MCLK/1/4.
  8. 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.
  9. 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
  10. 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.
  11. 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();
  12. 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
  13. 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 ...
  14. Ok, I've now done that: https://e2e.ti.com/support/wireless_connectivity/simplelink_wifi_cc31xx_cc32xx/f/968/t/567067