Loading ... Done - but the program does not run.

Programmichiere

Hello, I'm trying to load my first program (the hello world example).
No error when compiling and loading, but the program does not run.

Can anyone tell me what I'm doing wrong?




forums.parallax.com/discussion/download/126524/prima%20registrazione%20schermo-2019-04-23_15.34.55.mp4


ModEdit: Image attached summarising the video clip

evanh

Likely still need to add yourself to "dialout" group to give yourself privilege to use a comport freely.
Useful shell commands are:

# To list your participating groups
groups

# To list all existing groups
getent group

# To add a user to a group
sudo adduser [username] [groupname]

# To remove a user from a group
sudo deluser [username] [groupname]

Programmichiere

Thanks for the reply.
unfortunately that is not the problem, I am logged in as root.

root# groups
root tty disk audio lp dialout kmem video floppy cdrom tape tty plugdev lpadmin

The usb-serial converter works fine, and if I connect rx to tx, I can read what I write on the terminal.

evanh

Cool. I've just installed SimpleIDE myself now and have no issue with printing lots of hello's to the terminal. I note it requires the PropGCC tools too. In my case the deb package has everything but you may not have used that method of install.

There is a little hammer icon bottom-middle of SimpleIDE, clicking this will give you the build status. Here's what I get when clicking the Run-with-Terminal button:

SimpleIDE Version 1.0.1
/home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/
/home/evanh/hoard/coding/prop1/SimpleIDE/ Updated on: 2019-06-02

propeller-elf-gcc -v GCC 4.6.1 (propellergcc_v1_0_0_2411)
propeller-elf-gcc -I . -L . -I /home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools -L /home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools/cmm/ -I /home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L /home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/cmm/ -I /home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c -L /home/evanh/hoard/coding/prop1/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c/cmm/ -o cmm/Hello Message.elf -Os -mcmm -m32bit-doubles -fno-exceptions -std=c99 Hello Message.c -lm -lsimpletools -lsimpletext -lsimplei2c -lm -lsimpletools -lsimpletext -lm -lsimpletools -lm
propeller-load -s cmm/Hello Message.elf
propeller-elf-objdump -h cmm/Hello Message.elf
Done. Build Succeeded!

propeller-load -Dreset=dtr -I /opt/parallax/propeller-load/ cmm/Hello Message.elf -r -p /dev/ttyUSB0Propeller Version 1 on /dev/ttyUSB0
Loading cmm/Hello Message.elf to hub memory
8236 bytes sent

Verifying RAM ... 
OK

EDIT: Attached a screenshot of it running

evanh

Another idea: Leave the terminal open and try loading it to EEPROM instead.

It's possible there is an issue with DTR line causing too many resets of the propeller and thereby wiping out any download in RAM. With it stored in EEPROM, a reset will still run what's been downloaded.

avsa242

I'm not too familiar with the Simple Libraries, or C on the Prop in general, but does something have to be done explicitly to instantiate the serial driver (i.e., something analogous to ser.StartRxTx(31, 30, %0000, 115_200) in SPIN)?
Also do those high() and low() methods automatically set the dira register for the I/O pins as outputs? If not, I'd think that'd need to be done first, before toggling the output state.

EDIT: Sorry, disregard - glossed over the fact that this is a pre-made example from the learn.parallax.com site...

evanh

The print() function knows how to tx back on pin30. It's all built in. That's why the download for those few lines compiles to over 8000 bytes.

Programmichiere

evanh wrote: »

It's possible there is an issue with DTR

I tried to disconnect DTR while loading, but nothing change.
I can't load to eprom because I have no one.

The chip is mounted on a breadboard,maybe I should have specified it previously,
but I'm assuming the program is loaded correctly, because the ide give no errors and no warnings.
if I disconnect any pin the ide give errors, then the chip is dialoguing with the IDE.

I'm trying to reset manually the reset pin , but without positive results.

propeller-elf-gcc -v GCC 4.6.1 (propellergcc_v1_0_0_2411)
propeller-elf-gcc -I . -L . -I /root/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools -L /root/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools/cmm/ -I /root/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L /root/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/cmm/ -I /root/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c -L /root/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c/cmm/ -o cmm/Welcome.elf -Os -mcmm -m32bit-doubles -fno-exceptions -std=c99 Welcome.c -lm -lsimpletools -lsimpletext -lsimplei2c -lm -lsimpletools -lsimpletext -lm -lsimpletools -lm
propeller-load -s cmm/Welcome.elf
propeller-elf-objdump -h cmm/Welcome.elf
Done. Build Succeeded!

propeller-load -Dreset=dtr -I /opt/parallax/propeller-load/ -b ACTIVITYBOARD cmm/Welcome.elf -r -p /dev/ttyUSB0Propeller Version 1 on /dev/ttyUSB0
Loading cmm/Welcome.elf to hub memory
8140 bytes sent

Verifying RAM ...
OK

AwesomeCronk

Maybe a wiring issue on the breadboard?
Is this a Propeller Mini, Propeller FLiP, or a DIP chip?

VonSzarvas

If a DIP chip to breadboard, do you have the four bypass caps, and depending on the distance from your power source, maybe a bulk cap too?
Voltage drops could cause this.

The Mini and FLiP modules have the caps built in.

Programmichiere

I wired the chip exactly like described in the datasheet,
I tried with and without crystal.
Could the baud rate be influenced by the crystal frequency?
It's no mentioned in the simpletext.h File Reference

Cluso99

Since you say you’re using a chip on a breadboard, can you post a picture and the circuit you’re using?
Hope you have a 5MHz crystal and the bypass caps and all power and ground and BOE connected.
BTW I note that your code posted toggles P20 but the comment says P26.

yeti

Programmichiere wrote: »

Could the baud rate be influenced by the crystal frequency?

Sure it will.

evanh

Programmichiere wrote: »

I wired the chip exactly like described in the datasheet,
I tried with and without crystal.

Looking at page 5 of P8X32A-Propeller-Datasheet-v1.4.0_0.pdf, I see there is no capacitors shown. It also doesn't show any power regulator circuit. It's one of those informational diagrams, not really a full schematic.

Regarding the crystal, although a crystal is optional for some things, it is needed for stable comport emulation. And I'm not sure but the compiler defaults probably assume a 5 MHz part. Any other frequency will likely need software adjustments to suit. I'm not familiar enough with the Prop1 to answer this any more precisely, sorry.

frank freedman

I had a similar experience a while back where the program, pasm, (using bst) would compile and load. No terminal output. I could compile and load, but could not have the terminal up when doing this; the prop could not be recognized. Closed the IDE and enabled a terminal and reset the prop. Terminated terminal process prior to loading again. Worked, of course program had to be loaded to prom. I noted in your program that the comments all refer to pin26 whereas your code looks like it should be blinking pin 20. Is the led installed on the pin the code actually is assigned? Also does the led blink if you comment out the terminal message? The system a Linux mint18.x distro with BST.

evanh

I don't think he has any LED connected. He's looking for the "hello !!!" to repeat indefinitely in the terminal.

Dave Hein

Do you see P20 toggling? Are you using a 5MHz crystal? SimpleIDE assumes you are using a 5MHz crystal by default. If you are not using a crystal you will need to modify the board type that you are using to match your configuration. Click on the project view button in the lower left area of the SimpleIDE window. The project pane should become visible. Click on the board type, and select the RCFAST. The Propeller runs at approximately 12MHz with RCFAST. P20 should toggle at about the right speed, but serial I/O is unreliable with RCFAST. You need a crystal for reliable serial operation.

If you are using a crystal at some frequency other than 5MHz you will need to create a board configuration file with the correct frequency. We can help you create the board config file if needed.

frank freedman

The suggestion to check the LED was a form of the half split method of troubleshooting, or in this case debugging. The original post from the OP stated that the program was not running.

OK, what is not running, all or part? If the LED flashes, something is running, so no text, check the terminal settings or scope the serial channel to see if there is any activity. There is an LED in the code, why? Visual indication of the code running. Compile and load and what happened, LED (not)blinking, (no)serial neither or both? Need to know the test setup is correct before debugging the code.

What if it is a handshake issue with the serial line? Seen that by many people who think they can just hook up a null modem cable with Rx, Tx and GND. Maybe it works maybe not. Were the rts/cts or dtr/dsr looped back on each end of the null modem cable? If your computer is waiting on either of these, you will not transfer in either direction. So, you can't just say 9600,n,8,1. Your system may be set to use flow control and / or hardware handshake. Code may be correctly running and appear failed due to your computer configuration. Another process may have control of the port. Not likely the problem here as the OP said he can loop back his Rx with Tx and see characters typed. (Beware that this test will look fine if terminal is set for half duplex mode when you are really seeing what "should" be sent. If set to half duplex and really sending/receiving then a b c will look like aa bb cc..... )

Rayman

You definitely need bypass capacitors near the P1 chip. For the DIP chip, I usually use two 10 uF Tantalum caps on either side of the chip.
Between +3.3V and ground.
Things will not work right without these capacitors....

Programmichiere

Sorry, I replied without refreshing the page first.

I'm using the dip chip alone with a 47uF cap between vss and vcc and 15uF caps on either side of the chip.all electrolytic.

I think the crystal was faulty, tried with a 3.5 MHz one and got some garbled text over the serial, then the chip is alive.
Now I'm reading the datasheet to learn something about clock and crystal registers an how to write them inside the C program.


Thank you all for helping me solve this problem.

evanh

Aluminium canister capacitors, unlike tantalums, have poor high frequency performance. Recommend replacing the two 15uF with 100nF ceramics. Or go with tantalums like Rayman.

VonSzarvas

About the crystal value....

Propeller uses it's internal clock for programming, but will rely on the correct code settings for either the internal or external crystal to operate the code.

This might be why you are successfully programming the device, but cannot use the terminal features- as the terminal will require that the clock settings are set correctly in your code. If you change from 5MHz to 3.5MHz crystal, for example, then you will need a different clock setting in the code.


We are all guessing quite a lot here because we cannot see a picture of your circuit. If you could share that, then I'd think you'd get the right solution immediately.

But in the meantime, I would repeat the advice above that one (or many) of the following is the most likely culprit:

1. Code setting for the crystal must match the actual crystal. Search for these keywords in the Propeller datasheet: CLK, PLL, XINFRQ

2. Circuit must have a [b]ceramic[/b] decoupling cap on each VDD/VSS pair, typically 100nF

3. Every VDD must be connected to 3.3V

4. Every VSS must be connected to GND

5. Circuit should have a bulk capacitor (tant, alu or ceramic) reasonably close to the Propeller. Your 47uF sounds fine.

I think this makes a nice summary for other uses who find the same issues you have, so I hope you don't mind me listing these here.

I have a hunch that your code setting for the crystal might be the issue though. SimpleIDE sets that automatically based on the board type you select, so the code might be assuming a 5MHz crystal. With the CLK (etc..) commands you can override the settings for your own requirements.

Dave Hein

You could create a custom board type configuration file that uses a 3.5MHz crystal. Let us know if you want help with this.

Programmichiere

Thank you all for all these answers.

Here is the photos, even if it would have been more useful earlier, as suggested.

Note that I still have to replace caps and add an eprom.

A big error was to assume that the chip would recognize the crystal frequency by itself . I should have read the manual more carefully,
in fact on page 14 it is "clearly" written how the CLK register must be set.

P8X32A Datasheet rev1.4 at page 14 wrote:

... a copy of the value
written should be placed in the Clock Mode value
location (which is BYTE[4] in Main RAM) and the
resulting master clock frequency should be written to the
Clock Frequency value location (which is LONG[0] in
Main RAM) ...

Dave Hein wrote: »

You could create a custom board type configuration file that uses a 3.5MHz crystal. Let us know if you want help with this.

it would be nice, I found some info about boards cfg files and surprisingly the serial now works


# Propeller activity board configuration.

clkfreq: 3579545 <--- crystal freq
clkmode: 42 <--- decimal value of 00101010
baudrate: 115200
[ . . . . . ]





I would like to understand how to use asm instruction and get the same result writing directly the to the ram.

is writing to BYTE[4] equals to write CLKSET register?
is BYTE[4] intended as fifth byte in the ram memory?

Dave Hein

BYTE[4] just contains a copy of the clock mode. Another approach would be to use the clkset(mode, frequency) macro. It is defined in propeller.h as

do { \
  _CLKFREQ = (frequency); \
  _CLKMODE = (mode); \
  __builtin_propeller_clkset(mode); \
} while(0)

Cluso99

Byte[4] is the fifth byte in hub RAM as memory numbers from 0.
Note this is HUB RAM, as each Cog (CPU) has its' own RAM, called Cog RAM which can only be addressed as longs (4 bytes). Therefore its' address is $000-$1FF and where last/top 16 longs are Special Registers that your program will set to do certain things, such as reading/writing to the I/O pins.

It's great that you have straddled the Prop to take power from one side to the other This minimises any differences in the voltages between the power pins. From the pic, it looks like your supply is coming in from the left. Presuming this, keep the electro (electrolytic capacitor) on the left side as that is closest to where power originates from. Now you MUST add a 100nF (=0.1uF) Ceramic capacitor to each side of the prop across it's power and ground pins. This is to prevent noise. While it will mostly run without it, you can face erratic behaviour if you don't have them, depending on your circuit and what you are doing. Also put a 100nF ceramic across your EEPROMs power and ground pins right at the pins if possible.

Another point is your crystal. Lots of ICs require "tuning" caps usually from both crystal pins to ground. The prop provides these internally
Next, the crystal is specified to have a capacitance range - it's about 18-22pF IIRC, so your Crystal should match this. Unless your building something extremely delicate, then this mostly will not matter. Within the nominal range of these sized crystals, all that will matter is that your frequency will be a very tiny amount out. Nothing you are likely to do at this stage will matter, certainly not serial communications.

So, go enjoy yourself