Community
cancel
Showing results for 
Search instead for 
Did you mean: 
idata
Community Manager
1,415 Views

Curio running @22.5MHz on Intel Microcontroller Studio

Jump to solution

It looks like I managed to Brick my Arduino 101 using Intel Studio for Microcontroller. It look to me that the processor was running @ 22.5MHz instead of 32MHz. I thought that the Crystal osc may not be enabled. I tried to enabled it through register 0xb0b00008. This resulted in me bricking the module. I can no longer update my app or even the Microcontroller ROM. I have attached a jpg of the error I get when trying to update the microcontroller ROM through projects. Does anyone know how I can recover. I and using a JTAG flyswatter2 interface for flashing and debugging.

After bricking my Ardudio 101 I got a new one. When I load my program under Ardunio and run my SPI port @ 8MHz I get a clock period of .125us as expected.

When I update my ROM under Intel Microcontroller Studio and load my program my SPI port clock runs at .170us. It not just the SPI clock that is affected everything is slowed down by a factor of .703 as if the clock is running @ 22.5MHz instead of 32MHz.

I looked at location 0xB0800008 and it had a value of 0x00040002 this indicates it is running from the Silicon Oscillator not the Crystal Oscillator. Also the Crystal Oscillator has a trim of 15.03pf where the recommenced is 10pf. When I tried to change this to the Crystal I Bricked the 101.

The 101 has a crystal in the Curie module.

I am trying to develop a program with exact timing and need to use the crystal.

How do I change to the crystal without Bricking another 101?

0 Kudos
1 Solution
idata
Community Manager
69 Views

First the good news I was able to recover my bricked board. This is a post I made on the Developer Site. Intel Premier Support issue # 6000163744

 

Since I did not get a response to my last message I tried to ground all the I/O pins to allow me to stop executing my code and stay in the boot loader. I was successful in reloading the SE1000 boot loader that I was unable to load without the I/O shorted. When I removed the shorting jumpers the board was still inoperable due to the fact that my application was still loaded in the x86 and ran after the boot loader thereby disabling the clock again. I repeated the shorting of the I/O and this time I ran https://downloadcenter.intel.com/do wnloads/eula/25470/Arduino-101-software-package?httpDown=https://downloadmirror.intel.com/25470/eng/arduino101-factory_r ecovery-flashpack.tar.bz2 Flashpack utility restoring the 101 to factory values. This erased my x86 code and allowed the 101 to revert to Arduino 101 factory state. I can now use my board in ARDUINO or INTEL Studio by updating the ROM. I reloaded the BLINK routine. By selecting shorting the I/O one at a time I was able to determine that I/O5 on header J13 is the pin that must be held low to prevent exiting from the boot code. I/O5 on the 101 is connected to two pins on the Curio module (A3 & G2) I2S_RXD & PWM1_OUT. These pins on the Curio module are in turn connected to pin B08 & D11 on the Quark SE C1000 chip. Since both of these pins are connected together on the 101 I don't which pin actually prevents the boot loader from executing app code on reset. Since pin D11 is connected to the ARC sensor processor and pin B08 is connected to the x86 GPIO[15] , I2S_RXD I assume it is this pin.

 

 

Thank you for the help I am back up and running this time I will make sure the Crystal Osc is enabled, and stable before I switch to it.

 

 

I don't understand why the Studio uses the Silicon Osc instead of the Crystal. Not using the Crystal prevents using the UART since the BAUD rate would not be accurate or stable. In my case not having a TRIM value in my 101 BOOT cause me to run at 22.5MHz instead of 32MHz.

 

 

The CURIO module is a great device with all of its capability and power stick with it. As you know it is just a QUARK SE C1000 that is supported in the Studio with some additional I/O. I need to develop code in the x86 and ARC processor and that is why I started to use the INTEL Studio IDE.

 

 

Also you look at my post on the x86 Compiler optimization. I also don't understand how an INTEL processor (x86) that has been around for 36 years can have a Compiler inside an INTEL development studio that adds instructions (TEST) after an (AND) that servers no function except to slow down the code. Please keep making the device and tools better.

I do not have that code any more but it is real simple and real stupid.

I looked at location 0xB0800008 and it had a value of 0x00040002 this indicates it is running from the Silicon Oscillator not the Crystal Oscillator. Also the Crystal Oscillator has a trim of 15.03pf where the recommenced is 10pf or even 5.55pf for the 101 . When I tried to change this to the Crystal OSC I Bricked the 101.

I changed location 0xB0800008 from 0x00040002 to 0x00000008 in my startup of my application. This switches the clock from Silicon Oscillator to Crystal Oscillator. But I had not enabled the Crystal Osc before I switched to it. This caused my code and everything else (JTAG DEBUGER) to stop working. I could not recover because every time I rebooted it ran my startup code that stopped the clock. The fix is stated above by shorting I/O 5 to ground you can stop the boot loader from calling the APP code. I could then reload the 101 to factory

Also since I never got an answer on how to switch from the Silicon osc to the Crystal osc here is the code I used to do that successfully.

# define lock (*((volatile uint32_t *)(0xB0800004)))

# define power1 (*((volatile uint32_t *)(0xB0800008)))

power1 &= 0xFFF0FFFF; // set crystal trim tp 10pf

power1 |= 0x00070001; // set crystal trim to 5.55pf

power1 |= 0x00000001; // turn on the Crystal osc

while((lock & 0x00000002) == 0 ); // wait for stable Crystal OSC

clk_sys_udelay(50); // just to make sure

power1 |= 0x00000008; // switch to the Crystal osc

clk_sys_udelay(50); // just to make sure

power1 &= 0xFFF0FFFD; // turn off the Silicon osc power

I hope this helps others.

View solution in original post

8 Replies
idata
Community Manager
69 Views

Hi Russ,

 

 

Thanks for contacting us!

 

 

We're sorry to hear that you are having issues with Arduino 101. We would like to suggest you to follow the instructions to restore factory settings in this guide: https://www.zephyrproject.org/doc/1.4.0/board/arduino_101.html https://www.zephyrproject.org/doc/1.4.0/board/arduino_101.html, maybe it can help to recover the board.

 

 

Moreover, the Arduino 101 is manufactured by Arduino, and we would suggest you to contact the Arduino 101 forum (https://forum.arduino.cc/index.php%3Fboard%3D103.0 https://forum.arduino.cc/index.php?board=103.0) and they can provide you a more accurate answer regarding the board manufacturing.

 

 

Regards,

 

-Yermi

 

idata
Community Manager
69 Views

New information

I just purchased a Quark D2000 development board and installed it in Intel microcontroller studio. After updating its BOOT ROM and reading it location 0xB0800008 "Hybrid Oscillator Configuration 1 (OSC0_CFG1)" I get a value of 0x21640002.

This value also states the board is running on the Silicon Oscillator instead of the Crystal. It also has the MAX Crystal trim of 15.03pf but the 10 bit trim code for the Silicon Oscillator is 216. The Silicon Oscillator is running close to 32MHz on this board unlike my 101 that was running at 22.5Mhz with no trim.

I don't understand why the board would be running on the Silicon Oscillator when a Crystal is present on board.

Still have a BRICKED 101. I have been unsuccessful in all attempts to recover it.

idata
Community Manager
69 Views

Hi Russ,

We would like to know if you have contacted Arduino forum.

Regarding your Arduino 101 bricked, please try downloading the recovery pack from here: https://downloadmirror.intel.com/25470/eng/arduino101-factory_recovery-flashpack.tar.bz2 https://downloadmirror.intel.com/25470/eng/arduino101-factory_recovery-flashpack.tar.bz2 and follow the instructions on the included README file.

Regards,

 

-Yermi

 

idata
Community Manager
69 Views

I have tried https://downloadmirror.intel.com/25470/eng/arduino101-factory_recovery-flashpack.tar.bz2 https://downloadmirror.intel.com/25470/eng/arduino101-factory_recovery-flashpack.tar.bz2 . On a 101 that had it ROM updated using INTEL Microcontroller Studio and was still working but running on the Silicon Oscillator @ 22.5MHz I was able to reload the 101 BOOT ROM to a factory version and run it on Arduino IDE @ 32MHz. But on the 101 I BRICKED I receive the BOOT ERROR that is attached to my original post.

I have posted on the Arduino forum but I am not trying to develop in the Arduino IDE I need to develop on both the ARC and the x86 and I thought the Intel Microcontroller Studio was the best IDE to use.

I would still like to know the correct procedure to change from the Silicon oscillator to the Crystal oscillator So I can run things like the UART that need to have the stability and accuracy of the Crystal. I am reluctant to try it again because that is how I believe I BRICKED my first Curie. Is there a piece of code I can include in my startup that allows this switch. Is there any requirements that need to be met? Clearly the Curie can run on the Crystal since the Arduino BOOT does this.

idata
Community Manager
69 Views

Hi Russ,

 

 

Thanks for all the information provided. We would like to let you know that we are investigating your issue, and as soon as we find useful information we'll let you know.

 

 

We'll appreciate your patience during the meantime.

 

 

Regards,

 

-Yermi

 

idata
Community Manager
69 Views

Hi Russ,

 

 

We would like to know if you can share the code you used in order to test this behavior.

 

 

Regards,

 

-Yermi

 

idata
Community Manager
70 Views

First the good news I was able to recover my bricked board. This is a post I made on the Developer Site. Intel Premier Support issue # 6000163744

 

Since I did not get a response to my last message I tried to ground all the I/O pins to allow me to stop executing my code and stay in the boot loader. I was successful in reloading the SE1000 boot loader that I was unable to load without the I/O shorted. When I removed the shorting jumpers the board was still inoperable due to the fact that my application was still loaded in the x86 and ran after the boot loader thereby disabling the clock again. I repeated the shorting of the I/O and this time I ran https://downloadcenter.intel.com/do wnloads/eula/25470/Arduino-101-software-package?httpDown=https://downloadmirror.intel.com/25470/eng/arduino101-factory_r ecovery-flashpack.tar.bz2 Flashpack utility restoring the 101 to factory values. This erased my x86 code and allowed the 101 to revert to Arduino 101 factory state. I can now use my board in ARDUINO or INTEL Studio by updating the ROM. I reloaded the BLINK routine. By selecting shorting the I/O one at a time I was able to determine that I/O5 on header J13 is the pin that must be held low to prevent exiting from the boot code. I/O5 on the 101 is connected to two pins on the Curio module (A3 & G2) I2S_RXD & PWM1_OUT. These pins on the Curio module are in turn connected to pin B08 & D11 on the Quark SE C1000 chip. Since both of these pins are connected together on the 101 I don't which pin actually prevents the boot loader from executing app code on reset. Since pin D11 is connected to the ARC sensor processor and pin B08 is connected to the x86 GPIO[15] , I2S_RXD I assume it is this pin.

 

 

Thank you for the help I am back up and running this time I will make sure the Crystal Osc is enabled, and stable before I switch to it.

 

 

I don't understand why the Studio uses the Silicon Osc instead of the Crystal. Not using the Crystal prevents using the UART since the BAUD rate would not be accurate or stable. In my case not having a TRIM value in my 101 BOOT cause me to run at 22.5MHz instead of 32MHz.

 

 

The CURIO module is a great device with all of its capability and power stick with it. As you know it is just a QUARK SE C1000 that is supported in the Studio with some additional I/O. I need to develop code in the x86 and ARC processor and that is why I started to use the INTEL Studio IDE.

 

 

Also you look at my post on the x86 Compiler optimization. I also don't understand how an INTEL processor (x86) that has been around for 36 years can have a Compiler inside an INTEL development studio that adds instructions (TEST) after an (AND) that servers no function except to slow down the code. Please keep making the device and tools better.

I do not have that code any more but it is real simple and real stupid.

I looked at location 0xB0800008 and it had a value of 0x00040002 this indicates it is running from the Silicon Oscillator not the Crystal Oscillator. Also the Crystal Oscillator has a trim of 15.03pf where the recommenced is 10pf or even 5.55pf for the 101 . When I tried to change this to the Crystal OSC I Bricked the 101.

I changed location 0xB0800008 from 0x00040002 to 0x00000008 in my startup of my application. This switches the clock from Silicon Oscillator to Crystal Oscillator. But I had not enabled the Crystal Osc before I switched to it. This caused my code and everything else (JTAG DEBUGER) to stop working. I could not recover because every time I rebooted it ran my startup code that stopped the clock. The fix is stated above by shorting I/O 5 to ground you can stop the boot loader from calling the APP code. I could then reload the 101 to factory

Also since I never got an answer on how to switch from the Silicon osc to the Crystal osc here is the code I used to do that successfully.

# define lock (*((volatile uint32_t *)(0xB0800004)))

# define power1 (*((volatile uint32_t *)(0xB0800008)))

power1 &= 0xFFF0FFFF; // set crystal trim tp 10pf

power1 |= 0x00070001; // set crystal trim to 5.55pf

power1 |= 0x00000001; // turn on the Crystal osc

while((lock & 0x00000002) == 0 ); // wait for stable Crystal OSC

clk_sys_udelay(50); // just to make sure

power1 |= 0x00000008; // switch to the Crystal osc

clk_sys_udelay(50); // just to make sure

power1 &= 0xFFF0FFFD; // turn off the Silicon osc power

I hope this helps others.

View solution in original post

idata
Community Manager
69 Views

Hi Russ,

We're happy that you were able to solve the issue and thank you very much for sharing it with the community. It will help others.

Regards,

 

-Yermi

 

Reply