Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by simpleavr

  1. @@theprophet I would think that my missing packet issue is not related to boot430load.exe's usleep timing. I.e. What I saw is timing issue / buffer overwrite issue between packet 2 and 3 within a SetReport() operation. I suspect it's the different usb chipset + associated kernel driver timing them differently. So I would expect even if I run your binaries, I will still have issue on my windows box. But please upload the firmware + your boot430load.exe and I will try and see. From usbpcap output the set of the 3 packets (setup, data, status) all happened within the same 1/10,000, so it'
  2. @@theprophet OK, so I think I had found out how I am getting lost packets (4 byte data packets). But just not sure why you are not getting them. So eventually I pull up usbpcap again and found that for each transfer via usbSetReport(...), there is a trio of packets going to the msp430, I look at them closely and research also usb protocol details and they are doing what is expected. I.e. (1) setup packet, (2) data packet, and (3) status packet. And bbusb uses the same interrupt to handle all of them. For boot430, we look at the length of (2) data packet, and process them accordingl
  3. @@theprophet good that you had a scope and figured out the led impact. It began as a temporary thing I put in for debug and it never occurred to me to put in a series resistor. I would usually put in some kind of pulse off-off-off-on to limit the current if I am to direct drive leds, but I guess I missed it here. Will update my github repo and make an important note on this. Thanks. I am not working on testing w/ my setup this weekend as it's thanks giving holiday here. Will investigate the my missing packets in a few days.
  4. @@theprophet I tried your code earlier today on a cygwin + win7 box. There are no more errors from the usbSetReports(), from the commandline it appeared the transfer is very smooth. On my setup, I am missing quite a bit of packets (4 byte data) and the firmware flashed end up incorrect. (shorter as it miss some 4 byte packets). I spend an hour or so trying to trace it. The only finding so far is that . when the time threshold is breached, the inbuf / idx is not 32 (8x4) bytes, but somes 7x4, 6x4, 5x4. . I also tried to adjust the timing (uSleep() from commandline) but it did
  5. @@theprophet Glad to hear your progress. I assume the main memory writes is also OK as you mentioned the remaining issue is w/ interrupt vector writing. In this case I will wait for your update for testing before committing to github. Please post changes here and I would like to test them. I think both the xtal and non-xtal usb comms is reliable, it's just the fact that when we do flash write / erase, the cpu is stopped and if there are usb packets to handle, the interrupt handler cannot response. A single write (byte of word) will take (at a typical 500Khz flash clock) 30 cycles x
  6. Very nice and simple PCBs. The OLED and MCU pair makes a nice stop watch / kitchen timer thing. I use Fritzing from their 1st version and am impressed w/ what it can do now.
  7. That was the intention, to re-create those micro trainers of the mid 70s. In the end, The editor, disassembler turned out too hard to use, and you could loss interest using it standalone. I think the reason that being one has to have a good knowledge of msp430 assembly language / machine code to use it properly. And the msp430 instruction set is not small. OTOH, the LMC interpreter is easy (w/ it's limited instruction set) and serve me well when I need to demonstrate "how do computers work". I recently implement the TMS0800 calculator chip and turn the H/W into a vintage calculator
  8. @@JWoodrell Thanks and it would be great to learn how well bbusb (any variation) works on pcb builds. @@GeorgeHahn There was another thread specific to this bootloader based on the video. http://forum.43oh.com/topic/3251-bootloader-for-msp430/ The github link can be found there and now here also. https://github.com/simpleavr/boot430 I will probably update the repository mid-week to incorporate theprophets changes. If you are just looking for bootloading, G2553 has one built in (from factory) http://forum.43oh.com/topic/2361-value-line-bootloader/ and Ricta59 als
  9. @@Mac Hi Mike, my bad, did not spend enough time to check on the ascii diagrams. They should be like so, w/ the "booster" + LP layout it is easier to see. I took the lazy approach and map the msp430g2553 pinout w/ the LED pinouts (by just super-imposing most pins on top). I used a1 or P1.1 and b2 for P2.,2 in my diagrams. The whole button scanning scheme is just use all segments and add button in all available paths. I.e. Segment A as line, crosses path w/ B, C, D, E, F, G, H (7) Segment B as line, crosses path w/ C, D, E, F, G, H (6)..... B-A is same as A-B so cannot use
  10. @@theprophet Thanks for the heads-up. I noticed that when bytes can get through but no flashing. Got to play w/ your changes for a bit. Also the w/o crystal block will need the LED back on P2.6/7. Quick test shows it's working fine w/ the new scheme. But as you say it's still suffering from stability problem when flashing larger apps. When tried w/o actually flashing (for debugging), it's reliable, so that means the writing to flash somehow has a chance to break things. I.e. busy and cannot reply to host. So I tried to adjust the timing and found that usleep() may not be reliable
  11. @@theprophet Great, thanks for your contribution. I am kind of busy this week but will get to it early next week. Once confirm good, I will make revisions into the github repository so everybody can use. I know the flash writing do throw the timing off and when I load larger "apps", say 4k+ sized, I do need to load it a few times before all bytes can be written w/o error. I had previously neglected it as I kind of loss interest in refining the software. So it is very helpful of you to spend the time to improve it. If you can find a way to make it more reliable, by all means I will
  12. I would be interest to know the power consumption of this device. As it can define what role the device can play. I.e. Will it be possible to put it in use as a bug type battery operated wireless sensor? A casual read on documentations shows the "analog" part is 5V though.
  13. That's what I wanted to do next (well, when I regain interest if I got a good project idea). I.e. Have target "apps" presenting as HID devices, but still retain the capability to update / download new "apps".
  14. Bear in mind that the target "app" might also need to use interrupt, that's why we have to "branch" at ISR2. So peeking at PxIE may not be conclusive on who's taking control. On the 32Khz crystal, I would avoid it if I can. When using crystal, we need to have TimerA0 Interrupt, which introduce another "branch" for the "app", if the app also need to use timer interrupts. But I guess we can have both varieties.
  15. What's TF2? Something from the avatar? I thought it's Village People.
  16. Anyway, good news : after writing my previous post, I decided to change the bootload430 just a bit so that it conforms to the hid constraints I mentioned (1st byte is report ID, length must match the length reported by the device by its descriptor), and it works : the device successfully receives the usbSetReport() buffers Good. May be it's at the controller level that stopped my badly formed packets. I'm going to perform some more tests, to check exactly what needs to be conform to the hid, and if you agree I would like you to test on your device+pc the modified code. I think there
  17. Oh, Forgot to point out the most noticeable difference. Your log say the device is 1.0 while mine is 2.0. ;-) Good luck.
  18. @@theprophet Don't know how to make out of it. Please see my capture on a good run. My transfers (USBSetReport()?) are all in the "URB_CONTROL . out"s, You can see from the screen capture carrying the 1st block of app firmware "55 42 20 01"....(bottom pane) I had these URB_CONTROL going from host to device and another one from device to host, then a SET_CONFIGURATION, addition sets of these 3 exchanges until the app firmware is done. I don't know enough (and really don't want to spend time digging into USB details) to tell what's wrong from your log. But may be my run will
  19. Code for the adventurous. Launchpad w/ a G2553 is enough to run emulator via terminal, no LED + Button Booster needed. https://github.com/simpleavr/tms0800
  20. @@abecedarian Right on, exactly what I need. Thanks for the find. I did look at ebay and found another one (same) but the one I found goes for $15+ (w/ shipping) and it's way out of what I want to spend. I will get these to play w/. Now I need to figure out a way to drive them w/o additional circuitry. The look of it requires 9 digits + 8 segments, that's already 17 IO pins, then there is uart, etc. Might need to get the 28pin G2553 (which is OOS from newark.ca, they only have 20pin tssop or QFN). But I always tries to use all thru-hole. What to do? 595s? Decade decoder for digit scann
  21. It's bound to happen. Currently I am re-using a UI shield from my ez430trainer project. http://forum.43oh.com/topic/3013-ez430trainer-a-retro-style-single-board-computer/ I am trying to locate those bubble led displays. It would be interesting to have a single PCB build for a daily use calculator.
  22. @@theprophet Not much to offer here. You sure have persistence in your hobby. :thumbup: I am also curious on why it didn't work for you. I also search bootHID but did not find anything related. From the PC side I did add delays between the usbSetReport()s. The reason is that bbusb does not have a double buffer implementation and cannot handle packets too quickly. This may cause problem after a number of blocks (ex. when the msp430 needs time to write flash at 256 byte blocks). But it should not be what you experience. I.e. fails at the 1st usbSetReport(). At one stage while debugging t
  23. If you don't want to turn off compiler optimization (i.e. take away your -O? in your CFLAGS), you can declare int i as "volatile int i;" to avoid gcc optimize your compare 2000 check. I am not sure how gcc optimize, but I compile your code w/ listing and found out gcc thinks you just want to toggle bit0 continuously so he optimize it and make it blinks way fast. And we think the LED is constant on. You can think that gcc did a good job and had optimized your program for "speed". Now it blinks faster than you can see.
  24. @@theprophet Looks like you have to 1st reproduce bbusb03 (moving mouse) on linux before going any further. Shorter cables, bypass caps, etc. Your best bet may be to install the winusb debug trace and debug under windows. There is not much I can advise except if you need me to compare configuration and other things. Looks like you are spending comparable amount of time like when I first did this. Good luck.
  • Create New...