- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am modifying someone else's code. This is for a ham radio project. At some point in time, with some previous version of Creator the attached code worked. I have no idea what that version was. The issue that I am experiencing is the when viewing the main.c source of the bootloader project is reporting: "expected function body after function declaration" at the line:
CY_ISR(morse_interrupt).
Also, there many errors reported when viewing the morse_isr.c file. I'm sure it is something simple that I am over looking but I can't seem to clear the message(s) and I have a feeling this is causing the project not to function correctly. However, the code does compile without errors or warnings. I'm confused
Background info: The bootloader senses a "boot" pin and if active, initiates an interrupt routine to blink a led with a message, "BOOT" in this case and calls bootloader_start(). This is so Creator 3 bootloader host may upload new firmware. (Note: the led_test is a bootloadble project for testing to determine if the bootloader project is functioning correctly)
If the pin is not active, it passes through this and starts the main program.
If the new firmware is uploaded to the device with the miniprog3, the device simply does nothing. The USB interface is not activated and the LED does not blink.
I hope this makes sense. Sorry for the multiple fonts. IE does not play well with this web site. Thanks, Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are some issues with PSoC3 and the on-line code checker which flags statements as errorneous that aren't bad. Trust in the compilation which will reflect the reality and -as I tried- there seem to be no compiler errors or warnings with your code.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Bob,
Thanks for coming back to me. Bummer, I was hoping the issue with the bootloader was something as simple as a missing definition (or along that line). This means the cause of the issue of the bootloader not functioning is more deeply buried. As I mentioned, this code worked at one time. As far as I know, the source code is identical to the source that was compiled sometime about a year ago.
Thanks,
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The unconnected pin "BOOT" is driven high which will start the bootloader in code. Is that the polarity you wanted? Then, as I understand, the bootloader waits for 25 seconds for a command. That's what you want?
Why do you use a StatusRegister component and do not read the pin directly?
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
"The unconnected pin "BOOT" is driven high which will start the bootloader in code. Is that the polarity you wanted? Then, as I understand, the bootloader waits for 25 seconds for a command. That's what you want?
Why do you use a StatusRegister component and do not read the pin directly?"
All very good points. I will check on the initial state of the pin. I do know that the pin is taken to ground via a jumper when the user wants to upload new firmware. After looking a the PCB schematic, the configuration of the pin and the code, something is not lining up (so to speak). As for the 25 seconds on the bootloader that is a mistake on my part. I was experimenting in an attempt to getting things to work. The original set up has the bootloader set to an infinite wait. Good point on the status of the pin. As I have mentioned this was some else's code. I will look into simply sensing the pin directly.
Thanks so much for the help.
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you read a pin directly I suggest you bounce it in and out then execute
the boot. You might be able to get away w/o doing this. Possibly
the length of time in boot update will allow this. If you debouce plan on
some crappy switches exceeding 100's of mS bouncing.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you plan to jumper the BOOT-pin there will be no need for de-bouncing, instead it will be alright to read the pin after power-up and branch to the update-part of the bootloader when the pin reads zero.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello All,
Yes, the sequence of events are:1) Power down the device, 2) Move jumper to boot position, 3) power up,4) upload new firmware via bootloader host, 5) power down,, 6) move jumper to run position, 7) power up. Obviously this is not intended to be used very often. It is just not convenient. Most users (operators) of this device will only be updating firmware on a very occasional basis (may be once every two years). Updating is more frequent at the moment since I am modifying the firmware to add new functionality.
OK, I have modified the project based on previous recommendations. Please note I am updating the firmware via the miniprog3. The miniprog3 is also used for debugging the code (forgive me if I am stating the obvious, but details are important when trouble shooting issues such as this).
The firmware now works to a certain extent. If the boot jumper is placed in the boot position the bootloader takes over and the LED is blinked with the morse code message, "LOAD" in this case. Please note: bootloader is configured to wait forever.
However, if the jumper is not in the boot position (run) the device just sits there and does nothing (no message, no anything ). So the question is how do I get the bootloader project to "jump" to the "led_test" program if the boot jumper is not in the boot position? Please examine the main.c source in the bootloader project.
As I have mentioned this has worked in the past. The original author of this code supplies an original hex and elf file. If I set the bootloadable component in the "led_test" project to point to these files, everything works. I just can't get the source he supplies to work after being recompiled with PSoC Creator 3 SP1.
Thanks for your attention and patience. Sometimes I can be "thick as a brick"
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good point about the hard wired jumper.
But then these days why do you have a customer opening up a box to
move a jumper ? Hopefully an exposed slide switch or a buttonat minimum.
But then amatuer radio operators drink a lot of fluids of various kinds, so fluid
proof the box would be well received. Hence tactile overlay button.
Just a thought.
Regards, Dana.
KB1RHB
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah, a fellow ham. This is the Peaberry V2 SDR radio. It comes as a kit so there are already little hammy fingers in it . It really is good little rig. It is a clone of the very popular Softrock Ensemble RTXT but the Peaberry uses the PSoC 3 to control all the functioning of the rig. I am modifying the firmware to support internally generated CW / Iambic code. As background, the rub with the softrock clones has been the CW paddles port has never functioned very well due to high latency issues. But since the Peaberry has the PSoC3 and is almost totally firmware driven, it has been fairly straight forward to modify the original firmware to support real CW / Iambic operations (just like the big rigs do ). The new firmware actually does work very well (it is in BETA and I'm waiting for feedback). I just can't get the bootloader to work.
Ron / W4MMP
P.S. Some hams don't even have the Peaberry in a box. It is simply laying naked on their table
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Afaiutd (as far as I understand the datasheet) you have to call BootLoader_Start() in any case. To make that work for you, you should remove the infinite wait. Depending on your design (make connection to USB host first, set jumper, then power-up) you even may wait for just half a second or less. When the Bootloader is not star4ted there are only some dirty hacks to start the bootloadable.
Bob
Q: Why do java programmers always wear glasses?
A: The can't C#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
OK, thanks very much. I will give your recommendations much consideration. But I have to asks. What are the hacks?
Regards,
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a variable telling the bootloader whether it was a software reset and now the bootloadable should run or if the bootloader must take over control. I never used that, but when yoou inspect the bootloader.h file you might find something.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
Along the line of being "thick as brick" it took a while to figure what is wrong I located an old original source. When the boot pin is not active this function call is made: Bootloader_LaunchApplication . Apparently PSoC Creator 3 SP1 no longer externalizes this call. I found the call in the generated source file, bootloader.c. What do I set in my source so that I may call this function call? This will solve the issue if I can call it directly from my application. I put this in my source:
extern void Bootloader_LaunchApplication(void) CYSMALL; but it didn't help. Compiler still errors off with: Build error: L127: UNRESOLVED EXTERNAL SYMBOL SYMBOL: Bootloader_LaunchApplication . Is there something I need to set up in the lnker?
Thanks,
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is the fricken hack:
Bootloader_SET_RUN_TYPE(Bootloader_START_APP);
CySoftwareReset();
use that in main() to switch to Bootloadable.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
Thank you, thank you, thank you!!! That did the trick!.
I hope I have not annoyed with all of this and my questions.
Thanks again !
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not annoyed at all, Ron. You are always welcome! You may go to lunch right now...
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bob,
Just one last note . I have submitted a case with Cypress regarding this issue. Not sure how far it will go. One thing I have noticed since with working with this technology, while the chips themselves are very good and a great concept, Cypress's regression testing for backwards compatibility leaves something to be desired. I am a 25 year veteran of the CS and IT industries. I guess I have been lucky, the two major companies I have worked for during that period of time, had an absolute commitment to backwards compatibility. This not the first instance while working with this ham radio application where PSoC Creator 3 SP 1 is not compatible with the previous releases. The other issue was resolved fairly easily. This one was a bit sticky. (Off soap box).
Thanks again,
Ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think that keeping backwards compatibility can spoil the progress, can hinder to invent new technics, new chips. After some time the burden to support older designs or components can be a pain in the ass.
In the case of the BootLoader I agree with you that the function to start the bootloadable should not have been hidden but put into the .h-file to make it accessable from BootLoader.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But Creator comes with the older versions of all components. That should include the bootloader as well. You need to enable the display of hidden component (I think its somewhere in the preferences).
If you still have the original version of the project, you can also try to use it again, but this time without updating the bootloader.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From Cypress:
Hello Ronald, Apologies for the inconvenience caused. Yes you are right. You will face issues with Bootloader_LaunchApplication(). This issue is due to the updates done to Bootloader component in version 1.20. These issues are fixed in the upcoming version of bootloader component 1.30. One workaround to avoid this issue is to use bootloader component 1.10 in your project. You can do this by clicking on, Project -> Update Components -> Bootloader select version 1.10 instead of 1.20. Now Click on next and update the component. After configuring Bootloader component to 1.10 you will not face issues with Bootloader_LaunchApplication() function. Please let us know if this solves your issue. We are sorry for the inconvenience caused due to this issue. This issue will be fixed in the latest creator version PSoC Creator 3.1. Please let us know if you have any further questions. Thanks, Hima
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, I did not think of using the upgrade dialog to downgrade a component 🙂 But its easier I guess than replacing it (since it should retain the configuration, if any).