Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Phil

Pages: [1] 2 3 4
1
ATMELTM AT91SAM7X and AVR32 / Re: UC3A Device Support
« on: November 04, 2021, 06:22:56 PM »
Thank you, Mark.

I will take a close look at those cross over MCUs. They are very attractive.

Phil

2
ATMELTM AT91SAM7X and AVR32 / UC3A Device Support
« on: November 03, 2021, 12:43:54 AM »
Mark,

What is the status of support for AVR32 UC3A devices these days?  I have access to a processor, AT32UC3A0512-ALUT, which I am considering using to replace some harder to find NXP Kinetis processors.  I am considering porting the uTasker code over to this AT32 processor.  The uTasker docs say these chips have "medium support".  Not sure what that means.

Can you explain?

Thanks.

Phil

3
USB / Re: USB on Windows 10
« on: July 13, 2021, 11:52:49 PM »
Mark,

Thank you. However, this did not resolve the problem.  I will come back to this later and step through the code and report.  It is also obvious that I need to update my copy of uTasker.

I will report back once I get my copy updated to the latest version of uTasker and I have walked through the code.

Best regards,

Phil

4
USB / Re: USB on Windows 10
« on: July 09, 2021, 01:42:00 AM »
Mark,

Here is the USBPcap log from Wireshark, if this helps.

Regards,

Phil

5
USB / USB on Windows 10
« on: July 09, 2021, 01:18:06 AM »
Mark,

I obviously have a Windows 10 driver problem with my USB serial interface to my MK64 processor. I am wondering if you have experienced anything like this before.

When I connect my MK64 board via USB to a certain Windows 10 PC, the USB port is unreliable at best. I hear the Window's Chime when the MK64 is connected and the Device Manager shows the COM3 port connected. However, neither TeraTerm or Putty is able to connect for 10-15 seconds. Once connected, the menu interface seems to work just fine for a while then it hangs. The MK64 is not locked up or resetting. But, at this point, the port is unusable. Sometimes unplugging and plugging back in the cable from the PC to the MK64 frees up the port to work again.

I have other Windows 10 machines that work perfectly with the same MK64 device and same cable.

I have unloaded the Windows driver for the USB device and restarted the machine. Problem persists. This PC is a Dell Insperion or something like that built in 2018. A little old but still working well in all other aspects besides USB serial. No problems printing via USB. No problems with keyboard or mouse activity.

Thanks.

Phil

6
NXPTM M522XX, KINETIS and i.MX RT / Re: K64 ADC Results
« on: May 04, 2021, 01:02:32 AM »
Mark,

No joy.

ADC_CHECK_CONVERSION and ADC_START_OPERATION are not defined in my build. Maybe I have an older version of uTasker.

The following code is inside the handler.  When run (after the interrupt), this routine gets into an infinite loop waiting for the conversion.

Code: [Select]
    adc_setup.int_adc_mode = (ADC_GET_RESULT);
    fnConfigureInterrupt((void *)&adc_setup);                            // start operation now
    fnDebugMsg("\n\r\n\rResults: ");
    fnDebugHex(adc_results.sADC_value[adc_setup.int_adc_bit], (WITH_SPACE | WITH_LEADIN | WITH_CR_LF | 2)); // print out the result

and when I modify it for READ_ONLY as shown below, the routine always returns zeros for ADC return values.  Doesn't lock up but returns no values.

Code: [Select]
    adc_setup.int_adc_mode = (ADC_READ_ONLY);
    fnConfigureInterrupt((void *)&adc_setup);                            // start operation now
    fnDebugMsg("\n\r\n\rResults: ");
    fnDebugHex(adc_results.sADC_value[adc_setup.int_adc_bit], (WITH_SPACE | WITH_LEADIN | WITH_CR_LF | 2)); // print out the result

Like I said, I am able to generate interrupts but there are no results, likely because the conversion is not happening for some reason.

Regards,

Phil

7
NXPTM M522XX, KINETIS and i.MX RT / Re: K64 ADC Results
« on: May 03, 2021, 04:06:00 PM »
Mark,

In the last two statements of both examples below, the fnConfigureInterrupt sets an interrupt which will be handled by my handling routine (e.g. GetRotaryPos in my example). So, how is the second statement below the fnConfigureInterrupt going to be valid if they interrupt has not been tripped?  Are these fnConfigureInterrupt only for internal processes and not generating a change in the application/program pointer?  And, in both cases, shouldn't the checking of ucADC_status be in a loop waiting for the data to become valid?

Regards,

Phil

8
NXPTM M522XX, KINETIS and i.MX RT / K64 ADC Results
« on: May 03, 2021, 04:52:19 AM »
Mark,

I have been studying the uTasker ADC documentation, the forum, and ADC_Timers.c for quite some time. I think I understand the process fairly well. However, I am still unable to confidently get resultant data back from the ADC module as I would like.

I am trying to read the voltage on a variable potentiometer. 0-3.3V. Connected to SE14. I know the voltages are changing at the port. I am able to generate the interrupt depending upon the voltage. However, I am unable to see the actual line voltage as read from the ADC module.

Can you explain why I am unable to obtain a valid read from SE14 using the ADC module?

Step 1 - Initialization of ADC configuration:

    ADC_SETUP adc_setup;                        // ADC Setup Structure for Headphone Rotary Dial (POT)
    ADC_RESULTS adc_results;                     // ADC Raw Voltage Level of Headphone Rotary Dial (POT)
    #define AD_DA_BUFFER_LENGTH    (8 * 1024)                        // DMA buffer for 1s at 8k bytes/s
    static signed short sADC_buffer[AD_DA_BUFFER_LENGTH] = {0};      // 16 bit samples

    // ADC Setup for Headphone Rotary Dial (POT) Calibration
    adc_setup.int_type = ADC_INTERRUPT;                                  // identifier when configuring
    adc_setup.int_handler = 0;                                   // adc INT handler routine
    adc_setup.dma_int_priority = 3;                                      // priority of DMA interrupt the user wants to set
    adc_setup.dma_int_handler = 0;                                       // no interrupt so that free-running circular buffer is used (when ADC_FULL_BUFFER_DMA_AUTO_REPEAT is not defined)
    adc_setup.ucDmaChannel = 6;
    adc_setup.ptrADC_Buffer = sADC_buffer;                               // ADC sample buffer to be used
    adc_setup.ulADC_buffer_length = sizeof(sADC_buffer);                 // physical length of the buffer
    adc_setup.usDmaTriggerSource = 0;                                    // default trigger is the ADC conversion completion of the channel in question
    adc_setup.pga_gain = PGA_GAIN_OFF;                                   // {13} PGA gain can be specified for certain inputs
    adc_setup.int_priority = PRIORITY_ADC;                               // ADC interrupt priority
    adc_setup.int_adc_controller = 1;                                    // ADC controller 1
    adc_setup.int_adc_int_type = (ADC_SINGLE_SHOT_TRIGGER_INT);          // interrupt type
    adc_setup.int_adc_offset = 0;                                        // no offset
    adc_setup.int_adc_bit = ADC_SE14_SINGLE;                             // SE14 Pin
    adc_setup.int_adc_mode = (ADC_CALIBRATE | ADC_SELECT_INPUTS_A | ADC_CLOCK_BUS_DIV_2 | ADC_CLOCK_DIVIDE_8 | ADC_SAMPLE_ACTIVATE_LONG | ADC_CONFIGURE_ADC | ADC_REFERENCE_VREF | ADC_CONFIGURE_CHANNEL | ADC_SINGLE_ENDED_INPUT | ADC_SINGLE_SHOT_MODE | ADC_12_BIT_MODE | ADC_SW_TRIGGERED);
    adc_setup.int_adc_sample = (ADC_SAMPLE_LONG_PLUS_12 | ADC_SAMPLE_AVERAGING_32); // additional sampling clocks
    adc_setup.int_adc_result = 0;                                        // no result is requested at this stage
    fnConfigureInterrupt((void *)&adc_setup);   // Perform Configure and Calibration of ADC Channel

Step 2 - Setup the interrupt for the ADC:  (just triggering on any voltage below 1.0V, which seems to trigger properly)

    adc_setup.int_adc_controller = 1;                                    // ADC controller 1
    adc_setup.int_adc_bit = ADC_SE14_SINGLE;                             
    adc_setup.int_adc_int_type = (ADC_LOW_LIMIT_INT);                    // interrupt type (trigger only when lower than the defined level)
    adc_setup.int_low_level_trigger = (unsigned short)(ADC_VOLT * 1.0);  // the low level trigger threshold represented as input voltage (note: setting low threshold higher than the high threshold causes a trigger inside the range rather than outside of it)
    adc_setup.int_handler = GetRotaryPos;                                   // handling function
    adc_setup.int_adc_result = &adc_results;                               // I want to know the current value
    adc_setup.int_adc_mode = (ADC_SELECT_INPUTS_A | ADC_CLOCK_BUS_DIV_2 | ADC_CLOCK_DIVIDE_8 | ADC_SAMPLE_ACTIVATE_LONG | ADC_CONFIGURE_ADC | ADC_REFERENCE_VREF | ADC_CONFIGURE_CHANNEL | ADC_SINGLE_ENDED_INPUT | ADC_SINGLE_SHOT_MODE | ADC_12_BIT_MODE | ADC_SW_TRIGGERED); // note that the first configuration should calibrate the ADC - single shot with interrupt on completion {12}
    fnConfigureInterrupt((void *)&adc_setup);                            // start operation now

Step 3 - Evaluate the results of the analog line and setup the ADC for subsequent interrupts:

void GetRotaryPos(void)            // Service Routine for ADC Rotary Dial Read
{
    signed short rotary_raw;                     // value of SE14 pin voltage

    // ucADC_status[0] and [1] are always not valid (0)
    if (adc_results.ucADC_status[0] == ADC_RESULT_VALID)           // if the conversion is ready
        rotary_raw = adc_results.sADC_value[0];
    else
       rotary_raw = 0;

    // Relaunch ADC Interrupt for Headphone Rotary Dial (POT) - Get Value of Rotary Dial Position (voltage level)
    // ...

    return;
}

Result:  rotary_raw is always 0.  Goal: rotary_raw should be between 0.0 and 3.3.  In this interrupt example above, rotary_raw should be between 0.0 and 1.0.

Any suggestions?

Regards,

Phil

 

9
Thank you, Mark!

Most appreciated!

Phil

10
Mark,

Thank you.

Here was my final app_hw_kinetis.h config:

      #define OSC_LOW_GAIN_MODE                                            // oscillator without feedback resistor or load capacitors so use low gain mode
        #define CRYSTAL_FREQUENCY    25000000                            // 25 MHz crystal
        #define _EXTERNAL_CLOCK      CRYSTAL_FREQUENCY
   #define RUN_FROM_EXTERNAL_CLOCK                                  // run directly from external 25MHz clock
        #define CLOCK_DIV            10                                  // input must be divided to 2MHz..4MHz range (/1 to /24)
        #define CLOCK_MUL            48                                  // the PLL multiplication factor to achieve operating frequency of 120MHz (x24 to x55 possible)
        #define FLEX_CLOCK_DIVIDE    3                                   // 120/3 to give 40MHz
        #define FLASH_CLOCK_DIVIDE   5                                   // 120/5 to give 24MHz
   #define USB_CLOCK_GENERATED_INTERNALLY                           // use USB clock from internal source rather than external pin - 120MHz is suitable from PLL
   #define USB_CLOCK_SOURCE_MCGPLL1CLK                                  // {29} the clock source for the USB clock is dedicated to the FS USB interface (48MHz)

But, I had to also modify "kinetis_K_CLOCK.h" for the MC6_C1_FRDIV_VALUE for my crystal frequency. It set it to what I thought was closest:

#if !defined RUN_FROM_DEFAULT_CLOCK && !defined EXTERNAL_CLOCK && !defined CLOCK_FROM_RTC_OSCILLATOR // no configuration performed - remain in default clocked mode
    #if CRYSTAL_FREQUENCY == 8000000
        #define MCG_C1_FRDIV_VALUE    MCG_C1_FRDIV_256
    #elif CRYSTAL_FREQUENCY == 16000000
        #define MCG_C1_FRDIV_VALUE    MCG_C1_FRDIV_512
    #elif CRYSTAL_FREQUENCY == 24000000
        #define MCG_C1_FRDIV_VALUE    MCG_C1_FRDIV_1024
    #elif CRYSTAL_FREQUENCY >= 10000000 && CRYSTAL_FREQUENCY <= 12000000
        #define MCG_C1_FRDIV_VALUE    MCG_C1_FRDIV_256
    #elif CRYSTAL_FREQUENCY == 4000000
        #define MCG_C1_FRDIV_VALUE    MCG_C1_FRDIV_128
    #elif CRYSTAL_FREQUENCY == 32768
        #if !defined FLL_FACTOR
           #define MCG_C1_FRDIV_VALUE MCG_C1_FRDIV_RANGE0_1
        #endif
    #elif CRYSTAL_FREQUENCY == 25000000   // Added by Phil
        #define MCG_C1_FRDIV_VALUE    MCG_C1_FRDIV_1024
    #else
        #error crystal speed support needs to be added!
    #endif
#endif

Thank you again, Mark.

Phil

11
Mark,

This K64 has a 25MHz crystal connected at XTAL0/EXTAL0.  I can't seem to get past the "loop until.." in kinetis_K_CLOCK.h:

    while ((MCG_S & MCG_S_IREFST) != 0) {                                // loop until the FLL source is no longer the internal reference clock
            #if defined _WINDOWS
        MCG_S &= ~MCG_S_IREFST;
            #endif
    }

Here is what my app_hw_kinetis.h looks like:

//      #define OSC_LOW_GAIN_MODE                                            // oscillator without feedback resistor or load capacitors so use low gain mode
        #define CRYSTAL_FREQUENCY    25000000                            // 25 MHz crystal
        #define EXTERNAL_CLOCK       CRYSTAL_FREQUENCY
        #define _EXTERNAL_CLOCK      EXTERNAL_CLOCK
   #define RUN_FROM_EXTERNAL_CLOCK                                  // run directly from external 25MHz clock
        #define CLOCK_DIV            10                                  // input must be divided to 2MHz..4MHz range (/1 to /24)
        #define CLOCK_MUL            48                                  // the PLL multiplication factor to achieve operating frequency of 120MHz (x24 to x55 possible)
        #define FLEX_CLOCK_DIVIDE    3                                   // 120/3 to give 40MHz
        #define FLASH_CLOCK_DIVIDE   5                                   // 120/5 to give 24MHz
//   #define USB_CLOCK_GENERATED_INTERNALLY                           // use USB clock from internal source rather than external pin - 120MHz is suitable from PLL

Am I doing something wrong here?  I think it should be working but I don't see anywhere uTasker tells the osc block to use the XTAL0 port then enable the clock.

Thanks.

Phil



12
USB / Re: USE_USB_AUDIO
« on: October 28, 2020, 04:04:43 PM »
Thank you, Mark.

I will study these descriptors closely.  Great information!

Phil


13
USB / Re: USE_USB_AUDIO
« on: October 28, 2020, 04:22:16 AM »
Thank you, Mark.

I did read the uTasker USB Audio documentation prior to my last post.

My main issue was whether or not I could generate a USB Audio Class descriptor using the K64/K66 solution.  It is very important that the audio stream be recognized by Windows or Macs. You have given me more confidence that I have the correct design in mind.

Thank you again.

Phil

14
USB / USE_USB_AUDIO
« on: October 27, 2020, 12:49:18 AM »
Mark, et. al,

I am considering the USB Audio interface for a upcoming project.

I am receiving an analog or digital (I2S) SAI stream from a microphone source. I'd like to use the NXP MK64 processor to output the microphone source as a USB Audio Device so a Windows-based PC can recognize and use the microphone audio source. However, it is important that the USB is seen by Windows as a USB Audio Class Device so as to be usable in Skype or other soft codecs.

I can provide the audio in analog or digital format. I would think it would be better to keep this in the digital domain (I2S)?

I am thinking about using a MK66 with (2) USB ports, utilizing one for USB Audio and the other for firmware updates, CDC, etc.  Any concerns about this idea?

Thank you for your opinion.

Phil

15
NXPTM M522XX, KINETIS and i.MX RT / Re: KL27 ROM Bootloader with KDS
« on: June 16, 2020, 06:15:46 AM »
Thank you, Mark.

Most appreciated!

Pages: [1] 2 3 4