April 25, 2024, 05:28:27 AM

Recent posts

#91
STMP1 / Re: Olimex STMP1 SOM - Error s...
Last post by Titomax - March 27, 2024, 06:17:44 PM
Hi all,
I can confirm the problem described at the beginning by SteffenFuchs (Steffen thank you for your in deep analysis). We are using many STMP157-SOM-512-EXT on our mainboard and sometimes after normal shutdown the modules don't boot anymore. On the debug UART the boot procedure hangs after this messages:

U-Boot SPL 2021.04+olimex-1-20240312.134658 (Mar 12 2024 - 13:48:01 +0000)
Model: STM32MP1XX OLinuXino-SOM
Init AXP209 PMIC

We initially thought we broke the modules in some way but they started working again after about 20-24 hours after removing them from the motherboard and let them disconnected.

Now only 2 modules on the initial 11 refuse to boot, all the others boot again.

It's alarming that we don't have any guarantee that inside our final product they don't stop to boot again after a system restart.

Please investigate the issue as soos as possible as we need to stop production if an hardware failure is identified.

Thank you in advance
 


#92
A20 / Re: Issues with setting up PE2...
Last post by olecom - March 27, 2024, 05:54:29 PM
#93
SHIELDS / Re: SHIELD-LCD16x2 new firmwar...
Last post by Laurence123 - March 27, 2024, 03:58:27 PM
I used MPLAB-IDE, this new version is cleaned up and will hopefully load into the IDE as a project.
https://workupload.com/file/ypjLT3YxZMJ
#94
SHIELDS / Re: SHIELD-LCD16x2 new firmwar...
Last post by LubOlimex - March 27, 2024, 03:39:18 PM
Nice but can you give some details about what tools are used to compile it to build it? There is no project file.
#95
A20 / Re: Use of PI port as GPIO iss...
Last post by LubOlimex - March 27, 2024, 03:10:09 PM
Are PI02, PO03, PI18, PI19 defined elsewhere in the fex? CTRL + F ?

PI18 and PI19 are defined for SPI usually, you have to either remove them from there or define other pins.
#96
SHIELDS / SHIELD-LCD16x2 new firmware
Last post by Laurence123 - March 27, 2024, 02:38:20 PM
I have identified a number of issues with the 16x2 LCD and fixed them with a new firmware build for the PIC16F722A.
This is attached as a zip. Initial testing shows it is much faster, but the UART functionality has not been fully tested.
https://workupload.com/file/yupRn6mV78J
I2C has been tested at 100kHz. 400kHz seem to result in issues, appears related to the I2C peripheral on the PIC, which is in 100kHz mode by default. This can be swapped to 400kHz mode, but then according to the PIC16F datasheet there is a hardware timeout that will cause timeouts with bit-banged data exchange.
#97
ARDUINO / Re: Problem with Olimex ISP500...
Last post by pslhit - March 27, 2024, 09:37:01 AM
Quote from: LubOlimex on May 17, 2023, 02:10:43 PMIt should work. Did you follow the instructions on the product page? How to set it up with Arduino IDE? These five steps had been tested and confirmed working today with Windows 10 and Arduino 1.6.7:

1. Plug AVR-ISP500 to the computer via USB cable with a USB type B connector (we sell such a cable in case you don't have one).

2. If you have a newer version of Windows the drivers would install automatically. If they do not install automatically, download and manually install the drivers of AVR-ISP500 from the product page.

3. Before launching Arduino IDE you need to add a configuration for the Olimex programmer. It is simple – navigate to *\arduino-1.6.7\hardware\arduino\avr\ and open the file programmers.txt for editing. At the end of the file add the following:

olimexisp.name=Olimex AVR-ISP500
olimexisp.communication=serial
olimexisp.protocol=stk500v2
olimexisp.program.tool=avrdude
olimexisp.program.extra_params=-P{serial.port}

4. Launch Arduino IDE and select Tools –> Programmer –> "Olimex AVR-ISP500"; also select the COM port of the programmer as seen in "Windows Device Manager"(!)

5. Remember to click Sketch –> Upload using programmer – if you just click "Upload" then Arduino IDE would attempt to upload via the Run 3
By connecting RX to RX and TX to TX everything works.
#98
JTAG / Re: Faulty ARM-JTAG-SWD?
Last post by Artem - March 26, 2024, 06:24:08 PM
Hi!

Quote from: LubOlimex on March 25, 2024, 12:48:52 PMCan you upload a picture with the hardware connections and cables that show the JTAG connection? Also maybe a diagram with the signals at your target board so we can track if maybe some hardware discrepancy is going on.

Also make sure to test with the basic line in your openocd:

openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/at91samdXX.cfg

1. Photo of the setup A

Pins state (measured on JTAG-20-10 adapter on 20-pin connectors, debugger and JTAG-SWD adapter connected)

(1) VTref: 0.83V (after attempt to connect to openocd: 0.42V)
(3) nTRST: 0
(5) TDI: 0
(7) TMS: 0
(9) TCK: 2.56V (after attempt to connect to openocd: 0V)
(11) RTCK: 0
(13) TDO: 0
(15) RESET: 3.28V
(17) DBGRQ: 0
(19) 5V-supply: 4.98V

(*) Another exposed Vcc on target board: 3.28V (doesn't change at any moment)

2. Photo os the setup B

Pins state (measured on JTAG-20-10 adapter on 20-pin connectors, JTAG-SWD adapter disconnected)

(1) VTref: 3.28V
(3) nTRST: 0
(5) TDI: 0
(7) TMS: 0
(9) TCK: 0
(11) RTCK: 0
(13) TDO: 0
(15) RESET: 3.28V
(17) DBGRQ: 0
(19) 5V-supply: 0V

(*) Another exposed Vcc on target board: 3.28V (doesn't change at any moment)

3. Running one-liner code for Olimex doesn't change anything:
openocd -f interface/ftdi/olimex-arm-usb-tiny-h.cfg -f interface/ftdi/olimex-arm-jtag-swd.cfg -f target/at91samdXX.cfg Info : FTDI SWD mode enabled
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 400 kHz
Error: Error connecting DP: cannot read IDR

4. Connection via Atmel-Ice, for comparison:

openocd -f interface/cmsis-dap.cfg -f target/at91samdXX.cfgInfo : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: JTAG supported
Info : CMSIS-DAP: FW Version = 1.0
Info : CMSIS-DAP: Serial# = J41800043599
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 400 kHz
Info : SWD DPIDR 0x0bc11477
Info : [at91samd.cpu] Cortex-M0+ r0p1 processor detected
Info : [at91samd.cpu] target has 4 breakpoints, 2 watchpoints
Info : starting gdb server for at91samd.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : [at91samd.cpu] external reset detected
#99
A20 / Use of PI port as GPIO issue
Last post by morind79 - March 26, 2024, 03:02:52 PM
Hello,

I have a A20 Micro board and designing a daughter board that is adding a 8bit port (GPIO). I am still using an old kernel so use FEX script to setup the GPIO pins.
Here is an extraction of the 8bit port in FEX :

gpio_pin_63 = port:PI02<0><default><default><default>
gpio_pin_64 = port:PI03<0><default><default><default>
gpio_pin_65 = port:PC17<0><default><default><default>
gpio_pin_66 = port:PC18<0><default><default><default>
gpio_pin_67 = port:PC23<0><default><default><default>
gpio_pin_68 = port:PC24<0><default><default><default>
gpio_pin_69 = port:PI19<0><default><default><default>
gpio_pin_70 = port:PI18<0><default><default><default>

Then I try to set logic level for each individual bit of the 8bit port (I set logic level to 1 for 500ms and then to 0).
For the one attached to PC17, PC18, PC23 and PC24 all is working fine, LED blinks.
But for the 4 others using PI this is really strange because some are working well and suddenly PI02, PI03, PI18 and PI19 are set to HIGH even if I am not working on them ! Also if when I set HIGH to PI19, all PI02, 03, 18 and 19 get level HIGH, but if I try again with the same PI19, then all is ok. So I am completely lost here.

Can someone please help ?

Thanks
I tried to pinpoint from which bit it is doing that
#100
TERES DIY Laptop / Teres-1 debug console
Last post by DiTBho - March 26, 2024, 12:07:59 PM
I'm a bit puzzled ...

I have a Teres-1 RevC motherboard. On Revision C boards, a serial port is provided through the audio jack.



TX  RX
 |   |
=== == ====|||||||||---------
         |
        GND
Tx and Rx must be 3.3V LvTTL compatible.


.          |\
uart0 -----| \______ jack
audio -----| /
.          |/
.          |
.         sel <--- SoC.GPIO.port_L.bit9

sel: the uart can be enabled via an analog switch controlled by bit 9 on Port L,
  • pulled low  ---> uart0 connected to jack
  • polled high ---> audio connected to jack

In the next Rev(D?), could you put a jumper to exclude the GPIO that configures the analog mux, in order to force it to always be connected without any intervention of any software or firmware?

Or, can't we provide a connector on the motherboard to "pull out" (from the laptop-shell) the serial port in case of need?

Uart0 is very useful when you debug uboot and/or kernel.

I don't have a Teres-1 laptop on hand at the moment, without configuring anything on the port-L of the GPIO, what is the default behavior?

At early boot, without configuring the GPIO port L by neither uboot nor kernel, is the uart0 connected to jack or is audio connected to jack?